Path
Public`/.well-known/security.txt` should load on the deployed siteTrust Transparency
Verify public security contact paths before relying on them.
Use this checklist when reviewing `security.txt`, responsible disclosure wording, public contact links, and the boundary between site feedback and vulnerability reporting.
Scope
Defensivecontact text should invite safe reporting, not testing without permissionReview
Releaseconfirm contact, expiration, policy, and acknowledgements before launchFallback
Visibleusers should know where feedback ends and security reporting beginsVerification Steps
Check the public contact surface
1. Confirm the well-known file resolves
Open `/.well-known/security.txt` on the deployed domain and confirm the hosting platform serves it with the expected content type and no redirect surprises.
2. Verify contact ownership
Confirm the listed contact channel is monitored by the right owner and is not a personal inbox that could disappear without notice.
3. Check policy wording
Make sure the policy invites responsible reporting, discourages unauthorized testing, and does not promise response timelines the project cannot meet.
4. Review expiration and updates
If an expiration date is present, set a review reminder before it passes. Stale security contact metadata weakens trust quickly.
5. Separate site feedback from security reports
General page feedback can stay local or product-focused. Security reports need a contact path that can handle sensitive vulnerability details safely.
6. Avoid claiming a formal program too early
Do not imply bug bounty, legal safe harbor, coordinated disclosure terms, or response SLAs unless those are actually approved and operated.
Release check: verify `security.txt` after deployment, not only locally. Static hosting, redirects, and custom domains can change how well-known files are served.