Legal

Security policy

How to report a vulnerability affecting this site or anything I am responsible for, what you can expect in return, and the rules of engagement for good-faith security research. The companion machine-readable file lives at /.well-known/security.txt per RFC 9116.

Last updated: 10 May 2026.

Scope

This policy applies to:

  • The website at peterbassill.com and its www. alias.
  • The JSON API at /api/v1/*.
  • The admin area at /admin.
  • Any subdomain of peterbassill.com that I publish from this codebase.

It does not cover infrastructure operated by third parties on my behalf (the upstream hosting provider, Cloudflare, the email provider). Issues found in those should be reported to the relevant vendor; I am happy to forward a credible report on your behalf if helpful.

Reporting a vulnerability

Please send vulnerability reports to security@peterbassill.com or through the contact form.

A useful report includes:

  • A short summary of the issue and its impact.
  • The affected URL, parameter, or component.
  • Reproduction steps — concise and reliable, with sample requests / payloads where applicable.
  • Any proof-of-concept code or screenshots, ideally not relying on third-party hosting.
  • Your name or handle as you would like to be acknowledged, if at all.

Reports may be sent in plain text. PGP-encrypted reports are welcome — the public key is published at /pgp.asc and is also referenced from the Encryption: field of /.well-known/security.txt. Import with curl -s https://www.peterbassill.com/pgp.asc | gpg --import -.

What you can expect

  • Acknowledgement within 3 working days that the report has been received and is being looked at.
  • Triage within 10 working days, with an initial assessment of validity, severity, and whether it is in scope.
  • Status updates at reasonable intervals while the issue is being investigated and fixed.
  • Credit in the acknowledgements section below, if you would like it.

I aim to remediate confirmed vulnerabilities within these target windows, measured from confirmation:

  • Critical: 7 days.
  • High: 30 days.
  • Medium: 60 days.
  • Low / informational: 90 days.

These are targets, not guarantees — complex issues sometimes need longer, in which case I will say so.

Coordinated disclosure

I follow a coordinated-disclosure model. Please refrain from publicly disclosing the issue until a fix has been deployed, or until 90 days from the date of the original report — whichever comes first. If the 90-day window is approaching and a fix is genuinely not feasible, I will say so and we can agree an extension or a partial-disclosure schedule together.

Safe harbour

If you make a good-faith effort to comply with this policy:

  • I will not pursue legal action against you for testing, research, or disclosure that fits within these rules.
  • I will treat your activity as authorised under the Computer Misuse Act 1990 to the extent I am able to do so.
  • I will work with you, not against you, to understand and resolve the issue.

This safe harbour does not apply to activities that go beyond the rules of engagement below.

Rules of engagement

While testing, please:

  • Stay in scope. Do not pivot to upstream providers, peer sites, or unrelated systems.
  • Do not exfiltrate data. If a vulnerability gives access to data that is not yours, stop, capture only what is needed to demonstrate the issue, and report.
  • No denial of service. No load testing, traffic floods, password spraying, or anything else likely to affect availability for other visitors.
  • No social engineering. Do not phish, vish, or otherwise target me, friends, family, or any third-party staff.
  • No physical attacks on infrastructure or premises.
  • No persistence. Do not install backdoors, web shells, or implants. Remove anything you placed during testing.
  • Respect privacy. If you encounter another visitor's personal data, treat it as confidential, do not retain it, and report it.
  • Use your own accounts. Do not log in as me or attempt to take over an existing account.

Out of scope

The following are generally not considered vulnerabilities for the purposes of this policy:

  • Reports generated solely from automated scanners with no demonstrated exploitability.
  • Missing security headers on endpoints that do not return user content (e.g. /robots.txt).
  • SPF, DKIM, or DMARC findings without a credible spoofing demonstration.
  • Self-XSS or issues that require a victim to paste code into the browser console.
  • Theoretical CSRF on endpoints that have no state-changing effect.
  • Username or email enumeration with no further impact.
  • Click-jacking on pages with no sensitive state-changing actions.
  • Vulnerabilities in third-party libraries with no demonstrated impact in this site's deployment.
  • Issues affecting unsupported browsers (anything Microsoft has end-of-lifed, for example).

An out-of-scope finding is still welcome as feedback — it just sits outside the safe-harbour and disclosure-timeline commitments above.

No bug bounty

This is a personal site. There is no monetary bug-bounty programme. What I can offer is a prompt, technical, human response to your report, and credit in the acknowledgements below if you would like it.

Acknowledgements

With thanks to the security researchers who have responsibly reported issues affecting this site:

  • None publicly listed yet — be the first.

Machine-readable: /.well-known/security.txt · See also: Cookie policy · Privacy policy.