How do I prove my website is secure?

Why "secure" is not a provable property

"Secure" is a claim about the absence of every vulnerability, including ones nobody has discovered. Nothing can establish that. Anyone asserting it plainly is either being loose with language or selling something.

What is provable is the presence of specific controls, each individually observable. That is a weaker claim and a far more useful one, because it can be checked rather than believed.

What you can demonstrate

Every row is a fact about your responses that any visitor can confirm without your cooperation. That is what makes it a proof rather than an assurance.

What no external check can establish

Being explicit about this is part of the credibility, not a caveat that weakens it.

• Application logic. Injection flaws, broken access control, insecure direct object references. These need code review and testing, not header inspection.
• Dependency vulnerabilities. Requires knowing your dependency versions, which are not published — and version matching against CVE databases is explicitly out of scope here.
• Internal posture. Patch cadence, access controls, secrets handling, backups. Invisible from outside by design.
• Whether you have already been compromised. A well-run intrusion changes nothing observable from the outside.

Making the claim checkable

If you want to state a security posture publicly, the pattern that holds up is: state something specific, and link to where it can be verified.

• Publish security.txt. A machine-readable contact route for vulnerability reports at /.well-known/security.txt. Cheap, and it signals that reports are welcome rather than treated as attacks.
• Use a badge that links to a live audit, not a static graphic. A seal that is an image proves nothing; one that links to a re-runnable measurement can be checked by anyone.
• Say what you do not do. "We do not store card details; payment is handled by X" is specific and verifiable. "Bank-grade security" is not a claim about anything.
• Date it. A security statement with no date describes an unknown moment in the past.

A sensible order of work

1. Enforce HTTPS everywhere and add HSTS with a long max-age.
2. Add X-Content-Type-Options, X-Frame-Options and Referrer-Policy — minutes of work, no functional risk.
3. Introduce a CSP in report-only mode, watch what it would have blocked, then enforce it.
4. Remove version disclosure from server and runtime configuration.
5. Publish security.txt with a real contact route.
6. Re-measure and confirm each header is actually present in the served response, not merely in your configuration.

Step six matters more than it sounds. Headers set at the origin and stripped at the edge are common, and only measurement of the public response reveals it.