Security guide
HTTP security headers, explained
Response headers are one of the cheapest, highest-impact ways to protect the people who visit your website. This hub is the map: a short overview of every header worth setting, and a way into the topics that need more than one line of configuration.
Submitted scans are publicly listed on the recent scans page. By scanning, you accept our Terms and Conditions.
01 The headers
The headers at a glance
One card per header, with what it does, why it is worth setting and a line you can copy. Where a dedicated guide exists, the card links to it.
Strict-Transport-Security HSTS
What it does. Tells the browser to only ever reach your site over HTTPS, and to remember that decision for the given max-age. After the first visit, the browser upgrades every request to HTTPS itself, before any traffic leaves the device.
Why it matters. Without it, an attacker on the network can strip the first plain-HTTP request and downgrade the connection. HSTS closes that window and makes secure transport non-negotiable.
Recommended value. max-age=63072000; includeSubDomains; preload
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always; Content-Security-Policy CSP
What it does. Defines an allow-list of the sources a page may load scripts, styles, images and other resources from, and can forbid inline scripts entirely.
Why it matters. It is the single strongest defence against cross-site scripting (XSS). Even if an attacker injects a script tag, the browser refuses to run it unless the policy allows its source. Start in report-only mode, then enforce.
Recommended value. default-src 'self'; object-src 'none'; base-uri 'self'; form-action 'self'; frame-ancestors 'self'
add_header Content-Security-Policy "default-src 'self'; object-src 'none'; base-uri 'self'; form-action 'self'; frame-ancestors 'self'" always; X-Frame-Options
What it does. Controls whether your pages may be embedded in a frame or iframe on another site. DENY blocks all framing; SAMEORIGIN allows only your own origin.
Why it matters. It stops clickjacking, where an attacker overlays your site invisibly on theirs to trick users into clicking. Modern browsers also honour the CSP frame-ancestors directive, but this header covers older clients.
Recommended value. SAMEORIGIN
add_header X-Frame-Options "SAMEORIGIN" always; X-Content-Type-Options
What it does. Set to nosniff, it tells the browser to trust the declared Content-Type and never try to guess (sniff) a different one.
Why it matters. MIME sniffing can turn an innocent-looking upload into an executable script. Disabling it removes a whole category of content-confusion attacks with a single, safe value.
Recommended value. nosniff
add_header X-Content-Type-Options "nosniff" always; Referrer-Policy
What it does. Decides how much of the referring URL is sent when a visitor clicks a link away from your site or loads a third-party resource.
Why it matters. Full referrers can leak paths, tokens or search terms to other sites. A strict policy shares just enough for analytics while keeping sensitive URLs private.
Recommended value. strict-origin-when-cross-origin
add_header Referrer-Policy "strict-origin-when-cross-origin" always; Permissions-Policy
What it does. Lets you switch off powerful browser features such as camera, microphone and geolocation for your site and anything it embeds.
Why it matters. If your site never needs the camera, disabling it means a compromised or malicious embed cannot ask for it either. It shrinks your attack surface to only the features you actually use.
Recommended value. geolocation=(), camera=(), microphone=(), payment=(), usb=()
add_header Permissions-Policy "geolocation=(), camera=(), microphone=(), payment=(), usb=()" always; Set-Cookie Cookies
What it does. Not a security header in the strict sense, but the response header that decides how safe a session is: Secure, HttpOnly and SameSite control who and what may read a cookie and when it travels.
Why it matters. A session cookie without HttpOnly can be read by any script that makes it onto the page, and one without SameSite travels along with cross-site requests. Both turn a small bug into an account takeover.
Recommended value. name=value; Secure; HttpOnly; SameSite=Lax
Set-Cookie: name=value; Secure; HttpOnly; SameSite=Lax Cross-Origin-Opener-Policy COOP
What it does. Puts your pages into a browsing context group of their own, so a window that opened yours, or one your page opened, can no longer reach into it through the window reference.
Why it matters. Without it a cross-origin opener keeps a handle on your page and can probe its navigation state. It is also the first of the three headers a page needs before a browser grants it cross-origin isolation.
Recommended value. same-origin
add_header Cross-Origin-Opener-Policy "same-origin" always; Cross-Origin-Resource-Policy CORP
What it does. Declares who may embed your responses as a subresource: only your own origin, only your own site, or anyone at all.
Why it matters. It is the defence against side-channel attacks that read resources they were never allowed to see, and the only way to stop images, scripts and data files being pulled into someone else's page.
Recommended value. same-origin
add_header Cross-Origin-Resource-Policy "same-origin" always; Cross-Origin-Embedder-Policy COEP
What it does. Requires every cross-origin resource the page embeds to opt in explicitly, through CORP or CORS.
Why it matters. Only with COEP does the browser grant cross-origin isolation, which powerful features such as SharedArrayBuffer and high-resolution timers depend on. Beyond that it completes the isolation set: without it, resources from other origins end up in the process of the page without having agreed to it.
Recommended value. require-corp
add_header Cross-Origin-Embedder-Policy "require-corp" always; Reporting-Endpoints
What it does. Names the endpoint the browser posts reports to: policy violations, deprecations, crashes and, together with NEL, the network errors that never reached your server at all.
Why it matters. Without an endpoint every violation happens silently in somebody else's browser. It is the difference between a policy you can tighten with evidence and one you can only guess at.
Recommended value. default="https://example.com/report"
add_header Reporting-Endpoints 'default="https://example.com/report"' always;
add_header NEL '{"report_to":"default","max_age":10886400}' always; X-XSS-Protection Remove
What it does. The XSS auditor switch of old browsers. Current browsers ignore it, and the ones that still honour it apply a filter that has itself been used to break pages which were not vulnerable in the first place.
Why it matters. It creates no protection any more, but it does create the impression of one. In old browsers the filter can be steered from outside to suppress parts of a page or to leak content across origins, so the safe setting is not to send it.
Do not set this header. Send it switched off as shown, or better, leave it out entirely.
add_header X-XSS-Protection "0" always;02 Why they matter
Small headers, big protection
A browser trusts whatever your server tells it. Security headers are short instructions in every HTTP response that tell the browser how to behave: which connections to trust, what content it may load and how much information to leak. Set them well and entire classes of attack, from protocol downgrades to clickjacking and cross-site scripting, simply stop working. Leave them out and the browser falls back to permissive defaults.
03 In depth
Ten topics worth a page of their own
Most headers are a single line you set once. Eight are not: a content security policy has to be shaped around your own site, HSTS carries a decision you cannot quickly reverse, cookie flags live in your application rather than in your web server, and the referrer, permission and framing rules each trade a little convenience for a lot of protection. Two more sit outside the response entirely: the DNS records that stop mail being sent in your name, and the file that tells a researcher where to report what they found. And two deal with what happens after go-live: a header that was right on release day can be gone or loosened after the next deploy, and noticing that takes more than a one-off check. Each has its own guide.
Content Security Policy
The strongest defence against cross-site scripting: which directives to set, how to roll a policy out in report-only mode and how to reach an enforcing policy without breaking your site.
HSTS
Strict-Transport-Security explained: what max-age, includeSubDomains and preload actually do, and why the preload list is a decision you cannot quickly undo.
Cookie security
Secure, HttpOnly and SameSite: the cookie attributes that keep a session out of reach of scripts and cross-site requests, with the settings for a typical stack.
Clickjacking and X-Frame-Options
How an invisible overlay turns a visitor click into an action on your site, and the two headers that stop it: X-Frame-Options for older clients, frame-ancestors for everything else.
Referrer-Policy
Which part of your URLs travels to other sites when a visitor clicks away: the five policy values that matter, what each one gives up and the one to set by default.
Permissions-Policy
Switch off camera, microphone, geolocation and payment for your site and everything it embeds: the allow-list syntax, and why a feature you did not name is not a feature you turned off.
SPF, DMARC and DNSSEC
The records that stop someone sending mail in your name, and the one that keeps your DNS answers honest: what each does and the order to introduce them in.
security.txt
The file that tells a researcher where to report a vulnerability. Two mandatory fields, ten minutes of work, and the difference between a private report and a public one.
Monitoring security headers
A header that is right today can be gone after the next deploy. Three ways to notice: a cron job with curl, a check in your CI pipeline and a scheduled scan, with what each of them catches and misses.
Detecting CSP changes
How a policy changes quietly through deploys, plugins and CDN rules, and how to catch it: a header diff, violation reports through report-to, and what a scan comparison can and cannot show.
04 Server recipes
The same headers, for your stack
Knowing which header to send is half the job. These pages give you the finished configuration for the seven platforms we are asked about most, with the line-by-line explanation and the failure modes that make a configuration look correct while sending nothing.
Security headers in nginx
A complete server block to paste, what each add_header line does, and the inheritance rule that silently removes every header as soon as one location defines its own.
Security headers in Apache
The .htaccess block to paste, why mod_headers has to be enabled first and what the difference between set and always means for your error pages.
Security headers in WordPress
Every header with a few lines and no plugin, in a place a theme update cannot remove, plus the one policy that will break your block editor.
Security headers in IIS
The web.config block to paste, what each customHeaders entry does and why a web.config in a subfolder leaves you with the same header twice.
Security headers in TYPO3
Every header from one configuration array and no extension, why the backend needs a policy of its own and which files never reach TYPO3 at all.
Security headers in Shopware 6
A response subscriber that covers the whole storefront, why the administration has to be excluded and what a strict policy does to your payment providers.
Security headers in Plesk
The one field where your directives survive, why editing the generated vhost file is pointless and what proxy mode changes about duplicates.
05 Putting it together
A safe starting point
Add the directives inside the server block that serves your site, reload nginx and test. Roll out Content-Security-Policy carefully: begin with Content-Security-Policy-Report-Only, watch what would have been blocked, then switch to the enforcing header once the policy fits your site.
server {
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
add_header Content-Security-Policy "default-src 'self'; object-src 'none'; base-uri 'self'; form-action 'self'; frame-ancestors 'self'" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "geolocation=(), camera=(), microphone=(), payment=(), usb=()" always;
}Keep reading
More guides
Every guide stands on its own, and together they cover what our scanner looks at. Pick the one closest to your next question.
See which headers your site is missing
Our free Quickscan checks your live response headers alongside data protection, sustainability, accessibility, SEO and performance, then explains every finding in plain language.