Are your security headers set?
The response headers that tell browsers how to treat your pages: Content-Security-Policy, Strict-Transport-Security (HSTS), X-Content-Type-Options, frame protection, Referrer-Policy and Permissions-Policy.
Why it matters
These headers are safety nets. If something else goes wrong, for example a script slipped in through a form or a compromised third-party file, a good Content-Security-Policy limits what that script can do. Frame protection stops other sites showing your pages inside theirs to trick your users into clicks. Many hosts used by AI app builders send none of these by default.
How a survey checks it
Passive check: part of every free survey.
We read the headers your homepage sends to every visitor. Each missing or weak header is its own finding, with a severity that matches the risk: a missing Content-Security-Policy matters more than a missing Referrer-Policy.
How to fix it
- Add the headers where your host lets you set them: a headers file or setting on static hosts, or your framework's configuration on a server.
- Start a Content-Security-Policy in report-only mode, watch what it would block, then switch it on. A policy that breaks your own app is worse than none.
- Add HSTS only once every page and subdomain you use works on HTTPS.
Prefer us to do it? Ask for a fix quote
Common questions
Which security header matters most?
Content-Security-Policy usually does the most to limit damage, followed by HSTS. The others are small, cheap improvements worth adding at the same time.
Why is HSTS not flagged on my .app or .dev domain?
Those domains are on the browsers' HSTS preload list as a whole, so browsers already insist on HTTPS for them. We do not charge you for a header that would change nothing.