Guide
HTTP security headers: what to send and how to check them
4 minute read · Published
Which security headers your site should send
A modern site usually needs several headers working together: Content-Security-Policy to limit which scripts and resources the browser can load, Strict-Transport-Security to force HTTPS on future visits, and X-Content-Type-Options to stop the browser from guessing file types in unsafe ways. Each one covers a different risk, and the absence of just one is not always noticed until something breaks in production.
Add to that Referrer-Policy, which controls how much source URL information is sent to other sites, and Permissions-Policy, which restricts access to camera, microphone or geolocation from the domain itself or from iframes. None of these headers replace good code, but they reduce the impact of mistakes that already exist in the frontend or in third-party integrations.
How to check headers from the outside
The most direct way is to request the page with curl -I or with the browser's developer tools, in the network tab, and look at the full response, not just the HTML body. That is where every header the server decided to send shows up, including security headers, caching headers, and ones that needlessly reveal server technology.
It is worth repeating the check in production and not only in a test environment, because headers are often configured in a proxy or CDN that gets added right before launch, and that step is not always replicated in staging. It is also worth reviewing HTTP to HTTPS redirects, because a redirect without HSTS leaves a brief window where traffic travels unencrypted.
Common mistakes we see in reviews
A CSP policy with unsafe-inline or broad wildcards gives a feeling of being protected without providing much, because it allows almost any script. Another common pattern is HSTS present but without includeSubDomains, so a forgotten subdomain keeps accepting unencrypted connections even though the main domain is configured correctly.
On cookies, the Secure, HttpOnly and SameSite attributes are frequently missing, especially on session cookies created by older libraries with permissive defaults. On CORS, an Access-Control-Allow-Origin wildcard combined with credentials enabled is a mistake that often goes unnoticed in quick code reviews, precisely because it requires looking at the server's live configuration and not just the source code.
What Audixa does with live web configuration
Audixa reviews TLS, headers, cookies, CORS and redirects exactly as any visitor receives them, comparing what it observes against known practices. It does not execute the project's source code or install its dependencies; it works with what the server actually delivers and with what the repository shows, and it notes differences between the two when they exist.
Beyond web headers, Audixa looks for secrets in source code, risky code patterns and known dependency advisories, and it can note payment-provider mistakes such as a secret key exposed in client code or a webhook that skips signature checks. Each finding is delivered with the specific file or response where it appears, so the team can decide what to fix first.
Before launch: quick checklist
Before publishing it is worth confirming five things: active HSTS with includeSubDomains, a CSP that does not rely on unsafe-inline, session cookies with Secure and HttpOnly, CORS restricted to the origins that actually need it, and HTTP to HTTPS redirects without unencrypted intermediate steps. None of these require complex tooling, just checking the server's actual response.
Deleting a file with a key from the repository does not remove it from Git history, so that point is worth reviewing too before considering the list closed. To go deeper, the launch checklist guide and the note on secrets in Git history expand on several of these points with concrete examples.
Continue from here
Have the repeatable checks run for you
One project and one scan a month are free. You see how many findings there are and how severe they are; titles and evidence unlock on a paid plan.