Are security headers enough to secure a website?

Content Security Policy limits what a document may load and execute, which reduces the impact of an injected script rather than preventing the injection.

`X-Frame-Options` and `frame-ancestors` prevent your page being embedded, which defeats clickjacking.

`Strict-Transport-Security` makes a browser refuse plain HTTP for your domain once it has seen the header.

`X-Content-Type-Options`, `Referrer-Policy` and `Permissions-Policy` each close one specific browser behaviour.

Every one of these is enforced by the visitor's browser. None of them is enforced by your server, and none applies to a client that is not a browser.

Authorisation. A request that asks for someone else's data and is answered is a correct-looking request, and no header inspects it.

Injection into your database or your templates. A policy limits the damage of a successful injection; it does not stop the injection.

Credentials and secrets that reach the front-end, which are readable by anyone regardless of any policy.

Server-side flaws: unpatched software, exposed administrative interfaces, misconfigured storage.

Anything reached without a browser — an API called directly, a form posted by a script, a file fetched by a tool.

Denial of service, which is a capacity and routing problem rather than anything a response header influences.

Header scanners grade what they can see, which is a short list of response headers, and they say so. The grade is frequently read as a security assessment anyway.

A static site with no application behind it can score perfectly and has almost nothing to protect.

An application with genuine authorisation problems can also score perfectly, because none of the graded headers touches that.

A high grade is evidence of one configuration having been done, and it is not evidence of anything else.

It is still worth having: the headers are cheap, they close real browser-level attacks, and their absence is a reasonable signal that nobody has looked.

HTTPS everywhere, with a valid certificate covering every hostname and no mixed content — which headers assume rather than provide.

Cookie attributes: `Secure`, `HttpOnly` and `SameSite` on anything carrying a session.

Keeping software current, which is the single measure with the best return and the least glamour.

Authentication on anything private, rather than relying on a URL being unguessable.

Not shipping secrets to the browser, and rotating any that were shipped.

Rate limiting on authentication endpoints, which is one of the highest-return controls available and lives on the server rather than in a header.

VeriFixScan reports the headers a page actually returned — `security.csp`, `security.x_frame_options`, `security.referrer_policy`, `security.permissions_policy` and the rest — plus cookie attributes and TLS configuration.

It reports observable exposure: public source maps, secrets in public files, a `Server` header disclosing a version, a listable directory.

It does not test authorisation, does not attempt injection, and does not authenticate. Those require permission and a different kind of engagement entirely.

So a clean report means the observable surface is in order. It is a floor, not a verdict on the application.