Security Header Generator
Build browser security headers while explaining HSTS, CSP, framing, MIME, referrer, permissions, and isolation tradeoffs.
Core browser-security policies
HSTS rollout
Generated security headers and deployment warnings will appear here.
Security Headers Are Browser Instructions, Not a Security Score
A response header can change what the browser is willing to load, expose, frame, send, or remember. That can remove useful attack surface, but the header does not know whether your authorization checks are correct, your dependencies are patched, your sessions are protected, or your backend trusts unsafe input.
The generated policies are starters that explain the commitments behind them. It does not award a fake “A+” because six familiar header names are present.
HSTS Is Simple to Add and Potentially Expensive to Undo
Once a browser receives a valid HSTS policy over HTTPS, future navigation to that host is upgraded to HTTPS for the policy lifetime. With includeSubDomains, covered subdomains inherit the HTTPS-only rule. That is useful only when every affected host can remain reachable securely.
A preload commitment is stronger because participating browsers can know the rule before the user's first visit. The preload token is not defined by RFC 6797 itself and does not submit a domain anywhere. The official HSTS preload service documents the additional requirements, slow-removal risk, and why preloading should be a deliberate opt-in rather than a default.
CSP Usually Fails in Production Because the Real Dependency Graph Was Never Mapped
A modern page can load JavaScript, CSS, fonts, images, workers, frames, API connections, analytics, maps, payment scripts, video embeds and dynamically generated resources from several origins. A CSP that mentions only 'self' can therefore be syntactically valid and operationally destructive.
Start from the resources the page genuinely needs. Use Report-Only during rollout when appropriate, inspect violations, reduce broad source expressions, and move inline executable content toward nonces or hashes. Do not “fix” every violation by adding * or 'unsafe-inline'; that can erase the protection you were trying to deploy.
frame-ancestors and X-Frame-Options Overlap, but They Are Not the Same Mechanism
CSP's frame-ancestors controls which ancestors may embed the response in frames or related embedding contexts. X-Frame-Options: DENY and SAMEORIGIN are older framing controls.
CSP Level 3 specifies that an enforced frame-ancestors directive takes precedence over X-Frame-Options in conforming user agents. Keeping both can still be a compatibility decision, but they should express the same intent rather than contradict each other.
nosniff Helps Only When Content-Type Is Correct
X-Content-Type-Options: nosniff tells browsers not to reinterpret certain response bodies as another MIME type. That is useful when the server already sends accurate Content-Type values.
If your server labels JavaScript, styles, fonts, images, downloads, or API data incorrectly, nosniff can expose the mistake by causing the browser to reject the resource. Fix the MIME type rather than removing the security header to hide the problem.
Referrer-Policy Is a Data-Minimization Decision
Referrer information can help analytics and debugging, but full URLs can also reveal path or query information to another origin.strict-origin-when-cross-origin keeps more detail on same-origin navigation and generally sends only the origin on secure cross-origin requests, with stricter behavior on downgrade.
no-referrer is more private but removes useful attribution entirely. Choose based on what the site needs rather than treating one directive as universally “most secure.”
Permissions-Policy Can Break Features That Work Perfectly in Development
A policy such as camera=() disables that capability for the document and relevant descendants. That is excellent for a site that never uses a camera and incorrect for a QR scanner, identity-verification flow, video meeting or document-upload feature that needs it.
Start from the features the page genuinely uses. Feature names and browser support also evolve, so verify the current behavior of each directive you deploy rather than maintaining a giant copied policy forever.
COOP and CORP Solve Cross-Origin Isolation Problems That Ordinary “Security Header Lists” Often Ignore
Cross-Origin-Opener-Policy can isolate a top-level browsing context from cross-origin opener relationships. Cross-Origin-Resource-Policy lets a resource state which origins may load it in certain no-CORS contexts. They can be important for isolation and resource protection, but they can also disrupt federated login, payment popups, shared resources, image/CDN use, or integration windows.
They are opt-in here for that reason. A generator should not silently add isolation headers to every website simply because the names appear on a checklist.