Will adding these headers break my site?

Most of them won’t. Content-Security-Policy can, which is why the suggested policy starts in report-only mode: it reports what it would block without blocking anything. Cross-Origin-Opener-Policy can break pop-up sign-in and payment windows, so it is off unless you tick it.

Why does my grade differ from securityheaders.com or Mozilla Observatory?

Each tool weighs headers differently. This one gives the most points to Content-Security-Policy and Strict-Transport-Security, and also checks cookies, version leaks and the HTTP-to-HTTPS redirect. The fixes matter more than the letter.

Where do I set headers on AEM as a Cloud Service?

In the Dispatcher configuration: the vhost file for your site under dispatcher/src/conf.d/available_vhosts/, deployed through Cloud Manager. Validate it locally with the Dispatcher SDK first. Headers set in AEM code only reach visitors when Dispatcher and the CDN pass them through.

Do security headers need to be on every page?

Yes. Set them on every response, including error pages, redirects and files, which is what Header always set in Apache and always in Nginx do. Check a few pages, not only the home page.

Is the site I check stored or logged?

No. Live checks go through a small proxy that keeps no logs or copies, and pasted headers never leave your browser.

Security Headers Checker: Grade & Fix

User guide

What this tool does

The Security Headers Auditor reads the HTTP response headers a page sends and grades them from A+ to F. For each of the six headers that protect visitors, it explains what the header does, whether yours is set well, and what to change. It also checks cookies, headers that reveal your server software, outdated headers, cross-origin settings, and whether http:// redirects to https://. Then it writes the fix as configuration for Apache (including .htaccess), Nginx, AEM Dispatcher, IIS, or Netlify and Cloudflare Pages.

When to use it

Before a launch or go-live: check the production and staging sites.
After a security scan or penetration test flags missing headers: get the exact configuration to fix them.
After a server, CDN or Dispatcher change: headers are easy to lose when a vhost or CDN rule is rewritten.
When rolling out a Content-Security-Policy: see what your policy allows and what’s still missing.

How to use it

Choose the input.
- Live URL: type the page’s address and press Check headers. The page is fetched through this site’s proxy, which also checks whether the http:// address redirects to https://.
- Paste headers: for staging, intranet or pages behind a login. Run curl -sI https://your-site/, or in your browser’s DevTools open the Network tab, reload, click the first request and copy its Response Headers. Add the page address so the tool knows if it’s on HTTPS.
Read the grade and the cards. Each card shows a header’s value, its points towards the grade and what to do about it: ✕ is a problem, ! is a weakness, i is a suggestion and ✓ is fine.
Read the other checks under the cards: cookies, information leaks, legacy headers, cross-origin settings and HTTPS.
Pick your server in the Fix it panel. The list above the code shows what to add, keep, remove or try. Copy or download the configuration.
Test it on staging, then check again here. Watch for headers sent twice (by both the server and a CDN, for example).

To share a result, copy the address bar after a live check: it includes ?url= and runs the check again when opened.

How the grade works

Header	Points	What it protects against
Content-Security-Policy	30	Cross-site scripting: injected scripts running in your pages
Strict-Transport-Security	20	Connections downgraded to HTTP and intercepted
X-Frame-Options or CSP `frame-ancestors`	15	Clickjacking: your page hidden in another site’s frame
Referrer-Policy	15	Full URLs, with any tokens in them, leaking to other sites
X-Content-Type-Options	10	Files run as a type they aren’t, such as an upload as a script
Permissions-Policy	10	Injected code or embeds using camera, microphone or location

Weak values earn part of the points: for example, a CSP that allows 'unsafe-inline' scripts, or HSTS with a short max-age. The total out of 100 gives the grade: A+ from 95, A from 85, B from 70, C from 55, D from 40, otherwise F.

Two more rules apply. An A+ needs no serious problems in the other checks, such as a cookie without Secure or a broken CORS setup. A page on plain HTTP can’t score above D, and one whose http:// address doesn’t redirect to HTTPS can’t score above B.

Rolling out a Content-Security-Policy

CSP is the most valuable header and the easiest to get wrong. If you don’t have one, the tool suggests a starting policy as Content-Security-Policy-Report-Only, which only reports.

Add the report-only header and browse the site with DevTools open. Every violation appears in the console.
Add the hosts you really use to the matching directive: analytics to script-src and connect-src, fonts to font-src, embeds to frame-src.
Move inline <script> code into files, or give each inline script a nonce or hash, so you don’t need 'unsafe-inline'.
When the console stays clean on all page types, rename the header to Content-Security-Policy.

For AEM sites, check authoring previews, client libraries loaded from /etc.clientlibs, and third-party tags added through Adobe Launch (Tags), which often need extra hosts.

Where to put the configuration

Server	Where it goes	Watch out for
Apache	The site’s `.htaccess`, or its `<VirtualHost>`	Needs `mod_headers`. `ServerTokens` only works in the main server config
Nginx	The HTTPS `server { }` block	An `add_header` inside a `location { }` replaces all of the server’s headers for that location
AEM Dispatcher	The site’s vhost file, e.g. `conf.d/available_vhosts/site.vhost`	On AEM as a Cloud Service, deploy through Cloud Manager and validate with the Dispatcher SDK first
IIS	The site’s `web.config`	`removeServerHeader` needs IIS 10 or later
Netlify, Cloudflare Pages	A `_headers` file in the folder you publish	Only Cloudflare Pages can remove headers

If a CDN sits in front of your server, headers can be added or removed there too. Check the result from outside, with this tool, after every change.

Limits

The tool checks one response. Other pages, error pages and files can send different headers, so check a few.
It can’t tell which cookies your JavaScript needs to read, so a cookie without HttpOnly is a warning, not an error.
Some sites block automated requests or answer them differently. Use Paste headers with what your browser received.
The grade is a guide, not a security audit. A strong header set doesn’t make up for vulnerable code.

FAQ

Will adding these headers break my site?: Most of them won’t. Content-Security-Policy can, which is why the suggested policy starts in report-only mode: it reports what it would block without blocking anything. Cross-Origin-Opener-Policy can break pop-up sign-in and payment windows, so it is off unless you tick it.
Why does my grade differ from securityheaders.com or Mozilla Observatory?: Each tool weighs headers differently. This one gives the most points to Content-Security-Policy and Strict-Transport-Security, and also checks cookies, version leaks and the HTTP-to-HTTPS redirect. The fixes matter more than the letter.
Where do I set headers on AEM as a Cloud Service?: In the Dispatcher configuration: the vhost file for your site under dispatcher/src/conf.d/available_vhosts/, deployed through Cloud Manager. Validate it locally with the Dispatcher SDK first. Headers set in AEM code only reach visitors when Dispatcher and the CDN pass them through.
Do security headers need to be on every page?: Yes. Set them on every response, including error pages, redirects and files, which is what Header always set in Apache and always in Nginx do. Check a few pages, not only the home page.
Is the site I check stored or logged?: No. Live checks go through a small proxy that keeps no logs or copies, and pasted headers never leave your browser.