HTTP security headers explained: HSTS, CSP and more

What security headers are

Every HTTP response starts with headers: name and value pairs such as Content-Type: text/html. A handful of them change how the browser treats the page. They cost nothing to send, apply to every visitor and are set on the server, the hosting platform or a content delivery network, not in the page’s HTML.

IPNixa sets its own headers in a _headers file that Cloudflare serves with every page. The checker on this site requests the address you enter from our server, follows up to three redirects and reads the headers of the final response.

The six headers that matter most

These are the headers the checker rates. Values shown are common, safe starting points; adjust them to what your site needs.

How the IPNixa checker rates each header

Each header gets one of three states: present, review or missing. Review means the header exists but its value does not meet the rule below; it is a prompt to look closer, not a security score.

• HSTS is present when it appears once with a max-age of at least 15552000 seconds (180 days). A shorter or zero max-age is marked for review.
• CSP is present when it controls scripts through script-src or default-src and contains no 'unsafe-inline', 'unsafe-eval' or a bare * anywhere in the policy. A report-only policy is listed as missing, because it does not block anything.
• Framing is present with a frame-ancestors directive limited to 'none', 'self' or exact addresses, or with X-Frame-Options set to DENY or SAMEORIGIN.
• X-Content-Type-Options is present only with the value nosniff.
• Referrer-Policy is present when the last value is no-referrer, same-origin, strict-origin or strict-origin-when-cross-origin. Browsers use the last value they understand, so a list is judged by its final entry.
• Permissions-Policy is present when it is sent at all, because the right list of features depends on the site.

What real sites send: a sample

On 2 November 2026 we requested five home pages with the same user agent the checker uses and ran the responses through the IPNixa rating rules. Headers change often, so treat this as a snapshot.

Reading the sample: review is not the same as weak

GitHub’s policy limits scripts to its own asset host and specific hashes, which is strict. It is marked for review only because its style-src allows 'unsafe-inline', and the rule looks for that keyword anywhere in the policy. Inline styles are a much smaller risk than inline scripts, so this is a deliberate trade-off rather than a hole.

Our own site is marked for review for a different reason: its policy contains only frame-ancestors 'none', which blocks framing but does not restrict scripts. We report the result here as it stands.

Google’s home page sends its script policy as Content-Security-Policy-Report-Only, which reports violations without blocking them, and it did not send HSTS on this response; large sites can enforce HTTPS through other means such as browser preload lists. Wikipedia’s portal sends a very long HSTS max-age and little else on that page. None of this tells you whether these sites are secure overall; it shows which browser safeguards each response asks for.

Adding headers to your own site

Add one header at a time, reload your site, and check that pages, logins, embedded videos and payment forms still work before adding the next.

1. Start with the low-risk headers: X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin and X-Frame-Options: DENY, unless your pages must be framed by another site.
2. Add HSTS with a short max-age such as 300, confirm every subdomain works over HTTPS, then raise it to 31536000. Add includeSubDomains only when all subdomains support HTTPS.
3. Write a Content-Security-Policy and send it as Content-Security-Policy-Report-Only first. Collect violation reports or watch the browser console, fix or allow the legitimate sources, then switch to the enforcing header.
4. Add Permissions-Policy listing the powerful features you do not use, for example camera=(), microphone=(), geolocation=().
5. On nginx use add_header with the always flag, on Apache use Header always set, and on static hosting or a CDN use the platform’s headers file or response-header rules.
6. Run the IPNixa headers check again. For each missing header it shows a copy-ready line for nginx, Apache or a _headers file.

HSTS preload and other cautions

HSTS preload lists are built into browsers, so even the very first visit uses HTTPS. Submitting a domain requires a max-age of at least one year, includeSubDomains and the preload directive, and removal takes months to reach users. Only submit when every subdomain, including internal ones, will stay on HTTPS.

X-XSS-Protection is obsolete; modern browsers ignore it and a CSP replaces it. The cross-origin isolation headers (Cross-Origin-Opener-Policy, Cross-Origin-Embedder-Policy and Cross-Origin-Resource-Policy) are not rated by the checker, because they are needed only by sites that use features such as shared memory, and turning them on can block third-party embeds.