Contact

Tools  /  Security  /  HTTP Security Header Reference

SECURITY

HTTP Security Header Reference

Every HTTP security header explained with syntax and recommended values, an interactive CSP builder, and ready-to-paste config snippets for Nginx, Apache, Express, and Next.js -- a reference and generator, never a live scanner.

More Security tools

Password Generator JWT Decoder & Generator HMAC Generator Hash Identifier Random Token Generator UUID Validator

What this tool does

A reference catalog of every common HTTP security header -- what it does, its syntax, and a reasonable starting value -- an interactive Content-Security-Policy builder that constructs a real policy directive by directive, and a config generator that turns your chosen headers into ready-to-paste snippets for Nginx, Apache, Express, and Next.js. This is a reference and generator, not a scanner -- for grading a live site's actual response headers, use this site's Security Headers Checker instead.

Why these headers exist

Most security headers exist to turn off something the web platform allows by default but that most sites don't actually need -- being framed by another site, loading scripts from anywhere, leaking a full referrer URL to third parties, or letting any embedded page use the camera. Each header is an opt-in restriction, and browsers only enforce what a site explicitly asks for, which is exactly why a site with none of these headers set is still fully functional -- just less defended against a specific category of attack.

Content-Security-Policy, built interactively

CSP is the most powerful and most error-prone of these headers -- a single misconfigured directive can either leave a real gap (an overly permissive script-src) or break the site outright (forgetting a legitimate CDN). The CSP Builder tab lets you toggle directives and sources and see the exact resulting policy string build up live, rather than hand-assembling it from memory.

Cross-origin isolation: COOP, COEP, and CORP

Cross-Origin-Opener-Policy, Cross-Origin-Embedder-Policy, and Cross-Origin-Resource-Policy work together to isolate a page from other origins strongly enough to unlock powerful browser APIs like SharedArrayBuffer. They're also the headers most likely to break something if deployed carelessly -- COEP's require-corp value in particular can block third-party embeds (ads, widgets, some CDN-hosted assets) that don't send a matching CORP header themselves. Stage these in a report-only or test environment before enforcing them on a production site that embeds third-party content.

Privacy

Everything -- the reference, the CSP builder, and the config generator -- runs entirely in your browser. Nothing is sent anywhere, and no live request is ever made to any site.

FAQ

Frequently asked questions

Does this tool check my site's actual headers?
No -- this is a reference and generator. To audit a live site's real response headers with a letter grade, use this site's Security Headers Checker instead.
Which headers should every site set at minimum?
Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options: nosniff, and Referrer-Policy are the most broadly applicable starting point. X-Frame-Options is largely superseded by CSP's frame-ancestors directive but is still worth setting for older browser compatibility.
What is the difference between X-Frame-Options and CSP frame-ancestors?
They do the same job -- controlling whether the page can be embedded in an iframe -- but frame-ancestors (part of CSP) is the modern standard and supports multiple allowed origins, which X-Frame-Options cannot. Browsers that support CSP ignore X-Frame-Options when both are present and conflict.
Why would COEP break my site?
require-corp mode blocks loading any cross-origin resource (images, scripts, iframes) that doesn't explicitly opt in with its own Cross-Origin-Resource-Policy or CORS headers -- which breaks many third-party embeds, ad scripts, and widgets that haven't been updated to send those headers.
Is X-XSS-Protection still worth setting?
No -- it's deprecated. The browser feature it controlled (a legacy reflected-XSS filter) has been removed from modern browsers, and setting it to the wrong value could historically introduce its own vulnerabilities. Rely on CSP for XSS mitigation instead.
Can I generate a CSP policy here instead of writing one by hand?
Yes -- the CSP Builder tab lets you toggle directives and allowed sources and shows the exact resulting policy string as you go, then copy it directly into your config.
Is anything I configure here sent anywhere?
No. The reference, builder, and generator all run entirely in your browser -- this tool has no server component and never makes a request to any external site.
Theme Accent