Scan any URL for CSP, HSTS, X-Frame-Options, Referrer-Policy and 9 more security headers. Get a weighted score, letter grade and specific fixes. Free tool.
Enter a URL and this analyzer fetches the response headers, checks thirteen security-relevant headers, and returns a weighted score from 0 to 100 with a letter grade from A+ down to F. Every header gets a pass, warn, or fail status, the value that was actually returned, a severity rating, and a specific recommendation — not just “this header is missing” but what to set it to and why. You can also paste raw headers instead of supplying a URL, which is how you check a staging environment, an internal host, or a response captured from your browser’s network tab.
This is the check to run before a launch, after a CDN or reverse-proxy change, and whenever a client or auditor asks why a scanner gave your site a low security-header grade. It is deliberately fast and narrow: one HTTP request, one clear scorecard, exportable as CSV, with the raw headers copyable in one click.
Thirteen headers are analysed, weighted by how much real protection they provide:
'unsafe-inline' or 'unsafe-eval', or uses nonces or hashes. A policy relying on nonces or hashes scores far higher than one that permits inline script.max-age value is parsed and compared against one year (31536000 seconds), with additional credit for includeSubDomains and preload.DENY or SAMEORIGIN.nosniff.Referer header.Alongside the grade you get the HTTP status code, response time, protocol, a list of missing headers, and a note if the response looks like it came through Cloudflare — useful context, because a proxy in front of your origin is often the thing adding or stripping headers.
www and apex, and between origin and CDN.curl -I and paste them one per line as Header-Name: value. Note that HTTPS is assumed in this mode, since there is no URL to inspect.CSP tells the browser which sources of script, style, images, frames, and connections are legitimate. Its value is that it turns a successful injection into a blocked request: an attacker who manages to write a <script src="//evil.example"> tag into your page achieves nothing if script-src does not list that host.
The difficulty is that most real policies contain 'unsafe-inline', which is exactly the thing CSP exists to prevent, and is usually added because a site has inline event handlers or inline <script> blocks it cannot easily remove. The analyzer scores this honestly: a policy with both 'unsafe-inline' and 'unsafe-eval' is marked as a high-severity finding even though the header is technically present. A policy using per-request nonces (script-src 'nonce-{random}') or content hashes ('sha256-…') scores near the top, because those permit exactly your scripts and nothing else.
A sensible progression: start with Content-Security-Policy-Report-Only plus a reporting endpoint, watch what would break for a week, then move to enforcement with default-src 'self', an explicit allowlist per directive, and frame-ancestors. Add object-src 'none' and base-uri 'self' — both are cheap and close off real bypasses. If you are building a policy from scratch, the CSP Policy Generator assembles the directive string for you.
Strict-Transport-Security tells the browser to refuse plaintext HTTP to your domain for the duration of max-age, which defeats downgrade and SSL-stripping attacks on every visit after the first. A typical strong value is max-age=31536000; includeSubDomains; preload.
The three parts do different jobs. max-age under a year is treated as a warning here because short windows leave a large re-exposure gap. includeSubDomains extends the rule to every subdomain, which is what stops an attacker using a forgotten HTTP-only subdomain to set cookies for the parent domain. preload signals your intent to be included in the browser preload list, so the very first request is protected too.
Treat includeSubDomains and preload with care. Both are hard to reverse — the preload list ships inside browsers, and removal takes months. Confirm that every subdomain, including internal tools and legacy hosts, has a valid certificate and serves HTTPS before you enable them. The SSL Checker is the natural companion check.
X-Frame-Options stops your pages being loaded inside someone else’s frame, which is the mechanism behind clickjacking. DENY blocks all framing; SAMEORIGIN allows only your own origin. It is an old header with a coarse model — it has no allowlist — and the modern replacement is the CSP directive frame-ancestors, which accepts a list of permitted origins and is what browsers prefer when both are present. Ship both: frame-ancestors for correctness, X-Frame-Options for older clients.
Referrer-Policy controls how much of the current URL is sent when a user navigates away or loads a third-party resource. The default in most browsers already trims the path for cross-origin requests, but if your URLs carry tokens, session identifiers, or internal record IDs, an explicit strict-origin-when-cross-origin or no-referrer prevents that data landing in someone else’s logs.
Permissions-Policy (formerly Feature-Policy) disables browser capabilities the page has no business using. A value such as camera=(), microphone=(), geolocation=(), payment=() costs nothing on a site that never uses them, and it applies to embedded third-party frames too — so a compromised ad or widget cannot prompt your users for their microphone.
The cross-origin trio — COOP, COEP, CORP — is a different category. They isolate your browsing context from other origins and are what gate access to high-precision timers and SharedArrayBuffer. Enabling COEP in particular can break third-party embeds, so it belongs on a considered roadmap rather than a quick-win list. Expect-CT and X-XSS-Protection are reported for completeness but are deprecated; X-XSS-Protection’s legacy auditor was removed from browsers and, in some configurations, introduced bugs of its own. X-XSS-Protection: 0 is a defensible modern setting.
This is worth stating plainly: a header scan is a starting point, not a security assessment. It inspects one HTTP response. It cannot see your authentication logic, your authorisation checks, your SQL queries, your dependency versions, your secrets handling, your access controls, or your backups. A site can score A+ here and still be trivially exploitable through an IDOR in its API, and a site with a mediocre grade may be perfectly well defended by other means.
Two specific limits. First, headers can vary by route: your marketing pages, your login page, and your API may all return different sets, and the analyzer checks the single URL you gave it. Second, an intermediary such as a CDN or WAF may add headers that your origin does not send, so the result describes what users receive, not what your application produces — which is exactly why the Cloudflare detection note is displayed. Treat a good grade as evidence of hygiene, and pair it with dependency scanning, authenticated testing, and a real review before calling anything secure.
Thirteen: Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, Cross-Origin-Opener-Policy, Cross-Origin-Embedder-Policy, Cross-Origin-Resource-Policy, Expect-CT, X-XSS-Protection, X-Permitted-Cross-Domain-Policies, and X-DNS-Prefetch-Control.
Each header receives a score, and the scores are combined using fixed weights — CSP is weighted most heavily, then HSTS, then X-Frame-Options, then the rest. The weighted result maps to a letter: 95 and above is A+, 85 is A, 75 is B, 65 is C, 50 is D, and anything below that is F.
Presence is not the whole scoring. A CSP containing 'unsafe-inline' and 'unsafe-eval', or an HSTS max-age shorter than one year, scores well below a correctly configured equivalent. The table shows the returned value next to each finding so you can see which directive cost you the points.
Yes — use the paste mode. Capture the response headers with curl -I https://internal.example or from your browser’s network tab, then paste them one per line in Header-Name: value format. In this mode HTTPS is assumed, because there is no URL for the tool to inspect.
Both. frame-ancestors is the modern directive, supports an origin allowlist, and takes precedence in browsers that support it. X-Frame-Options remains as a fallback and costs nothing to keep.
Only once every subdomain reliably serves valid HTTPS. Preload is baked into browser releases and removal takes months, so a subdomain without a working certificate becomes unreachable for anyone whose browser has the entry. Run with a long max-age and includeSubDomains for a while first.
No. It means your HTTP response headers are configured well. Application logic, authentication, authorisation, dependencies, and infrastructure are all outside what a single response can show. Use this as one input among several.
Something between your origin and the browser is almost certainly modifying them — a CDN, reverse proxy, WAF, or platform edge layer can add, override, or strip headers. The analyzer reports what a client actually receives, which is the thing that matters, and flags when the response appears to be Cloudflare-served.
They add a few hundred bytes per response and no measurable latency. There is no direct ranking effect, though HTTPS enforcement and avoiding mixed-content or clickjacking problems help indirectly by keeping pages loading correctly for users and crawlers.
The analysis is performed by fetching the URL you submit and grading the response. Nothing about your site is published or stored for later, and you can avoid submitting a URL at all by using the paste mode.
Header hardening usually sits alongside transport and mail checks. Use the SSL Checker to confirm the certificate chain behind your HSTS policy, the Email Authentication Validator for SPF, DKIM, and DMARC, and the DNS Lookup Tool to confirm which host is actually answering for the name you tested.
HTTP security headers are directives sent by a web server in its HTTP response that instruct the browser to enable specific security features. These headers are one of the most effective and lowest-cost defenses against common web attacks including cross-site scripting (XSS), clickjacking, MIME-type sniffing, and protocol downgrade attacks.
Security headers require no changes to application code — they are configured at the web server or CDN level and take effect immediately. Despite their simplicity, many websites still lack critical security headers, leaving users vulnerable to attacks that were solved years ago.
| Header | Purpose | Prevents |
|---|---|---|
| Content-Security-Policy (CSP) | Controls which resources the browser may load | XSS, data injection, clickjacking |
| Strict-Transport-Security (HSTS) | Forces HTTPS for all future requests | Protocol downgrade attacks, cookie hijacking |
| X-Content-Type-Options | Prevents MIME-type sniffing | Drive-by downloads from content type confusion |
| X-Frame-Options | Controls iframe embedding | Clickjacking |
| Referrer-Policy | Controls what URL information is sent in the Referer header | Information leakage to third parties |
| Permissions-Policy | Controls browser feature access (camera, mic, geolocation) | Unauthorized feature access by embedded content |
| Cross-Origin-Opener-Policy | Isolates browsing context | Spectre-type side-channel attacks |
| Cross-Origin-Resource-Policy | Controls cross-origin resource loading | Data leaks via cross-origin requests |
CSP is the most powerful and complex security header. It defines an allowlist of content sources for each resource type:
Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' 'unsafe-inline'; img-src *; frame-ancestors 'none'
Each directive controls a specific resource type: script-src (JavaScript), style-src (CSS), img-src (images), frame-ancestors (who can embed your page), and more.
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload and submit your domain to the HSTS preload list for maximum protection.HTTP security headers instruct browsers how to handle your website securely: Purpose: Configure browser security features, prevent common web attacks, defense-in-depth layer (doesn't replace secure code but reduces impact), easy to implement (add headers in web server config). Key security headers: (1) Content-Security-Policy (CSP) - Controls resource loading (scripts, styles, images), prevents XSS attacks, restricts inline scripts/styles. (2) Strict-Transport-Security (HSTS) - Forces HTTPS connections, prevents SSL stripping attacks, includes subdomains and preloading. (3) X-Frame-Options - Prevents clickjacking, blocks iframe embedding, protects UI redressing attacks. (4) X-Content-Type-Options - Prevents MIME sniffing, stops browser from guessing content types, blocks polyglot attacks. (5) Referrer-Policy - Controls referrer information leakage, protects sensitive URLs, privacy enhancement. (6) Permissions-Policy - Restricts browser features (camera, microphone, geolocation), reduces attack surface, successor to Feature-Policy. Impact of missing headers: XSS attacks succeed (no CSP), clickjacking possible (no X-Frame-Options), MITM attacks easier (no HSTS), content type confusion (no X-Content-Type-Options), privacy leaks (no Referrer-Policy). Statistics: 97% of top sites use at least one security header (2024), only 5% use comprehensive CSP, sites with HSTS: 40%, X-Frame-Options: 60%. Implementation: Add headers in web server config (Apache, Nginx, IIS), or application code (Express.js, Django, Rails), verify with tools like this analyzer. Best practices: Implement incrementally (start with easy headers), test in report-only mode first (CSP), monitor violations, update as needed. This tool analyzes your headers and provides security score.
CSP controls what resources browsers load on your site: Purpose: Primary XSS prevention mechanism, define trusted sources for scripts, styles, images, fonts, etc., report violations for monitoring. CSP directives: (1) default-src - Fallback for other directives, typically 'self' (same origin). (2) script-src - Control script loading, most critical for XSS prevention, avoid 'unsafe-inline' (defeats purpose!). (3) style-src - Control stylesheet loading. (4) img-src - Control image sources. (5) connect-src - Control XHR, WebSocket, fetch destinations. (6) font-src, media-src, object-src - Control fonts, audio/video, plugins. (7) frame-ancestors - Replace X-Frame-Options, control who can embed your site. (8) report-uri / report-to - Where to send violation reports. Example CSP: Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted-cdn.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; report-uri /csp-report. Meaning: default: only same-origin resources, scripts: only from same origin + trusted CDN, styles: same origin + inline styles (temporarily for migration), images: same origin + data URIs + any HTTPS, violations reported to /csp-report. Implementation steps: Step 1: Start with report-only mode - Content-Security-Policy-Report-Only: <policy>, monitor violations without breaking site, analyze reports to refine policy. Step 2: Eliminate inline scripts - Move inline scripts to external .js files, use nonces or hashes for unavoidable inline scripts, refactor event handlers (onclick → addEventListener). Step 3: Enable strict policy - Remove 'unsafe-inline', remove 'unsafe-eval', whitelist only trusted domains. Step 4: Deploy and monitor - Switch to enforcing mode, monitor violation reports, adjust policy as needed. CSP nonces (recommended approach): Generate random nonce per request, add to CSP: script-src 'nonce-{random}', add to script tags: <script nonce="{same-random}">, only scripts with matching nonce execute. CSP hashes (for static inline): Hash inline script content (SHA256), add to CSP: script-src 'sha256-{hash}', only scripts with exact hash execute. Common pitfalls: (1) Using 'unsafe-inline' (defeats XSS protection), (2) Allowing 'unsafe-eval' (enables dynamic code execution), (3) Overly permissive wildcards (https:// allows any HTTPS domain), (4) Not monitoring reports (miss attack attempts). Testing tools: Browser DevTools (shows CSP violations), CSP Evaluator (Google), this security headers analyzer. Migration strategy: Start with report-only + permissive policy, gradually tighten based on reports, typically 2-4 week migration for complex sites. Advanced features: CSP Level 3 features: strict-dynamic (trust propagation), nonce-based policies (easier than whitelisting), worker-src (for web workers). CSP is most powerful security header but requires significant implementation effort.
HSTS (HTTP Strict Transport Security) forces browsers to use HTTPS: Mechanism: Server sends header: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload, browser remembers for max-age seconds (1 year = 31536000), all future requests to domain use HTTPS (even if user types http://), browser refuses non-HTTPS connections. Protection against: (1) SSL stripping attacks - Attacker downgrades HTTPS to HTTP, intercepts traffic, HSTS prevents downgrade (browser enforces HTTPS). (2) Accidental HTTP - User types example.com (defaults to HTTP), HTTP redirect to HTTPS can be intercepted, HSTS forces HTTPS from start. (3) Mixed content - Resources loaded over HTTP on HTTPS page, HSTS upgrades to HTTPS automatically. HSTS directives: (1) max-age - How long to remember HSTS policy (seconds), recommended: 31536000 (1 year), start shorter for testing (e.g., 300 = 5 minutes). (2) includeSubDomains - Apply policy to all subdomains, recommended if all subdomains support HTTPS, dangerous if any subdomain doesn't have SSL. (3) preload - Request inclusion in browser preload list, browsers ship with hardcoded HSTS for your domain, ultimate protection (works on first visit). Implementation steps: Step 1: Ensure HTTPS works - Valid SSL certificate for all domains/subdomains, test all site functionality over HTTPS, fix mixed content warnings. Step 2: Add HSTS header (short duration) - Strict-Transport-Security: max-age=300 (5 minutes), test for 1-2 weeks, verify no issues. Step 3: Increase duration - Gradually increase: 1 week → 1 month → 1 year, final: max-age=31536000. Step 4: Add includeSubDomains - Only if all subdomains support HTTPS, test thoroughly. Step 5: Submit to preload list - Visit hstspreload.org, verify requirements (min 1 year max-age, includeSubDomains, preload directive, redirect HTTP to HTTPS), submit domain. HSTS preload list: Hardcoded in browsers (Chrome, Firefox, Safari, Edge), protection from first connection (no trust-on-first-use vulnerability), used by 150,000+ domains, removal takes months (plan carefully!). Limitations: (1) First visit vulnerability (without preload) - First connection might be HTTP (no HSTS yet), attacker can intercept first visit, mitigation: preload list. (2) Subdomain sprawl - includeSubDomains can break services without SSL, need comprehensive SSL coverage. (3) Removal difficulty - Once preloaded, removal takes 6+ months, test extensively before preloading. Testing: Visit domain over HTTP, verify redirect to HTTPS, check DevTools: Network tab shows "Redirect" to HTTPS, Security tab shows HSTS engaged. Common errors: (1) HSTS on HTTP responses (ignored by browser), (2) Too short max-age (<6 months for preload), (3) Missing SSL on subdomains with includeSubDomains, (4) Certificate errors break HSTS (browser refuses connection). Best practices: Always serve HSTS over HTTPS only, start with short max-age, test subdomains before includeSubDomains, consider preloading for high-security sites, never disable HTTPS after enabling HSTS (users can't connect!). This analyzer checks your HSTS configuration and compliance.
Clickjacking defense headers prevent UI redressing attacks: Clickjacking attack: Attacker embeds your site in invisible iframe, overlays attacker's UI with transparent iframe, user thinks they're clicking attacker's buttons, actually clicking your site (e.g., "Delete Account"), also called UI redressing. X-Frame-Options (legacy header): Simple header with 3 values: (1) DENY - Never allow framing (most secure), X-Frame-Options: DENY. (2) SAMEORIGIN - Allow framing by same domain, X-Frame-Options: SAMEORIGIN. (3) ALLOW-FROM - Allow specific origin (deprecated, poor browser support), don't use this. Limitations of X-Frame-Options: Can't specify multiple allowed origins, ALLOW-FROM poorly supported, replaced by CSP frame-ancestors. CSP frame-ancestors (modern): Part of Content Security Policy, more flexible than X-Frame-Options, Content-Security-Policy: frame-ancestors 'none'; (equivalent to DENY), Content-Security-Policy: frame-ancestors 'self'; (equivalent to SAMEORIGIN), Content-Security-Policy: frame-ancestors https://trusted.com https://partner.com; (multiple origins). Comparison: X-Frame-Options: simpler, older browser support, less flexible. CSP frame-ancestors: more flexible, modern approach, better for complex requirements. Best practice: Set both for maximum compatibility: X-Frame-Options: DENY + Content-Security-Policy: frame-ancestors 'none';. When to allow framing: (1) Embed widgets - Your site provides embeddable widgets, use SAMEORIGIN or specific origins. (2) Legitimate partners - Payment gateways, iframe integrations, use frame-ancestors to whitelist partners. (3) Same-site framing - Internal admin panels in iframes, use SAMEORIGIN. Testing clickjacking protection: Create test page: <iframe src="https://yoursite.com"></iframe>, attempt to load in browser, should see: "Refused to display in frame" (protection working), or site loads in iframe (no protection!). Browser behavior: Chrome: Blocks with console error, Firefox: Blocks with error message, Safari: Blocks silently. Common misconfigurations: (1) Setting X-Frame-Options on some pages but not all, (2) Using ALLOW-FROM (doesn't work), (3) Not testing after implementation, (4) Conflicting X-Frame-Options and frame-ancestors. Additional protections: (1) Frame-busting JavaScript - Detect if in iframe: if (top !== self) top.location = self.location;, unreliable (can be bypassed), use as defense-in-depth. (2) SameSite cookies - Helps prevent CSRF in iframes, complementary protection. Real-world clickjacking examples: (1) Twitter clickjacking (2009) - Tricked users into following attacker, spreading worm. (2) Facebook Like button clickjacking - Forced likes on attacker's page. (3) Payment authorization - User thought they were playing game, actually authorizing payment. For high-security apps: Use frame-ancestors 'none', implement frame-busting JS, monitor for embedding attempts, educate users about browser warnings. This tool checks if your site is protected against clickjacking.
X-Content-Type-Options prevents MIME type confusion attacks: MIME sniffing problem: Browsers try to be "helpful" by guessing content type, ignore declared Content-Type header if content "looks different", can execute malicious content disguised as safe types. Attack scenario: (1) Attacker uploads "image.jpg", file contains JavaScript code (but with JPEG extension), server sends: Content-Type: image/jpeg, old browsers sniff content and see JavaScript, browser executes JS (ignoring image MIME type!). The header: X-Content-Type-Options: nosniff - only value is "nosniff", tells browser: trust the Content-Type header, don't try to guess content type, refuse to execute if MIME type mismatches. Protection provided: (1) Prevents script execution - Browser won't execute JavaScript if Content-Type isn't script MIME type, blocks polyglot file attacks. (2) Prevents CSS injection - Won't interpret CSS if Content-Type isn't text/css. (3) Forces correct MIME types - Developers must set proper Content-Type, improves web security hygiene. How browsers handle nosniff: (1) Scripts: If Content-Type isn't JavaScript MIME type (application/javascript, text/javascript), browser refuses to execute, console error: "Refused to execute script". (2) Stylesheets: If Content-Type isn't text/css, browser refuses to apply styles. (3) Other resources: Blocks loading if MIME mismatch. Valid JavaScript MIME types: application/javascript (preferred), text/javascript (legacy but common), application/ecmascript, text/ecmascript. Implementation: Add header globally in web server config, Apache: Header set X-Content-Type-Options "nosniff", Nginx: add_header X-Content-Type-Options "nosniff" always;, IIS: Add via web.config. Testing: (1) Verify header present: curl -I https://example.com, check response headers. (2) Test MIME mismatch: Create .js file, serve with wrong Content-Type (text/plain), include in HTML: <script src="test.js"></script>, with nosniff: script blocked, without nosniff: script might execute (browser-dependent). Common mistakes: (1) Missing Content-Type - nosniff requires Content-Type to be set, missing Content-Type with nosniff causes loads to fail. (2) Wrong MIME types - Serving JS with text/plain breaks with nosniff, need correct MIME: application/javascript. (3) Not setting for user uploads - Most critical for user-uploaded content, prevents uploaded files from executing as scripts. Use cases: (1) File upload endpoints - Prevent uploaded malware from executing, force browsers to download instead of execute. (2) APIs serving JSON - Prevent JSON endpoints from executing as HTML/JS, use application/json MIME type. (3) CDN and static assets - Ensure resources load with correct types, prevent cross-site script inclusion. Related protections: (1) Content-Disposition: attachment - Force download instead of display, prevents execution in browser. (2) X-Download-Options: noopen - Prevent IE from opening files directly, forces save then open. Browser support: Universal support in modern browsers (Chrome, Firefox, Safari, Edge), legacy IE also supports, no downside to setting. Defense-in-depth: Nosniff doesn't replace input validation, still validate and sanitize uploads, set proper Content-Type headers, combine with CSP for maximum protection. Impact on legitimate sites: Requires correct MIME types for all resources, may break sites serving JS with wrong MIME, fix: audit and correct Content-Type headers. This analyzer checks if nosniff is properly configured.
Permissions-Policy (formerly Feature-Policy) restricts browser features: Purpose: Disable browser features your site doesn't use, reduce attack surface, prevent feature abuse (e.g., malicious ads accessing camera), control features in iframes. Syntax: Permissions-Policy: feature=(allowlist) - Example: Permissions-Policy: geolocation=(self), camera=(), microphone=(), payment=(self "https://trusted-payment.com"). Common features to control: (1) camera - Webcam access, disable if site doesn't need camera: camera=(). (2) microphone - Audio recording, same as camera for privacy. (3) geolocation - GPS/location access, only allow if needed: geolocation=(self). (4) payment - Payment Request API, restrict to trusted origins. (5) usb - WebUSB API access, disable unless hardware interaction needed. (6) accelerometer, gyroscope, magnetometer - Motion sensors, prevent fingerprinting. (7) fullscreen - Fullscreen API, control to prevent social engineering. (8) picture-in-picture - PiP mode, (9) screen-wake-lock - Prevent screen sleep. (10) autoplay - Video/audio autoplay. Allowlist values: (1) \u0000() - Block for all origins (most restrictive), example: camera=() = no camera access anywhere. (2) \u0000(self) - Allow for same origin only, example: geolocation=(self). (3) \u0000(self "https://trusted.com") - Allow for self + specific origins, whitelist trusted partners. (4) \u0000\u0000* - Allow for all origins (default, least secure), rarely use this. Example policies: Strict (recommended for most sites): Permissions-Policy: geolocation=(), camera=(), microphone=(), payment=(), usb=(), magnetometer=(), gyroscope=(), accelerometer=() Moderate (site uses some features): Permissions-Policy: geolocation=(self), camera=(self), microphone=(self), payment=(self "https://payment-processor.com") Implementation: Add header in web server config, or via meta tag: <meta http-equiv="Permissions-Policy" content="geolocation=(self)">, header preferred over meta tag. Migration from Feature-Policy: Old header: Feature-Policy: geolocation 'self'; camera 'none', New header: Permissions-Policy: geolocation=(self), camera=(), syntax differences: Features separated by commas (not semicolons), values in parentheses (not quotes), 'none' becomes (). Browser support: Chrome: Full support (Permissions-Policy), Firefox: Partial (still uses Feature-Policy), Safari: Partial support, Edge: Full support (Chromium). Testing: Check browser DevTools Console for policy violations, test features (e.g., try to access camera, should fail if blocked), verify header present: curl -I https://example.com. iframe delegation: Control features in embedded iframes: <iframe src="https://untrusted.com" allow="camera 'none'; microphone 'none';"></iframe>, even if your policy allows, iframe doesn't get access. Benefits: (1) Privacy - Prevent tracking via sensors, block unauthorized camera/mic access. (2) Security - Reduce attack surface (disable unused features), prevent malicious iframe feature abuse. (3) Performance - Browser can optimize (skip feature initialization). (4) Compliance - Help meet privacy regulations (GDPR, CCPA). Common policies by site type: (1) Blog/content site - Block all: camera=(), microphone=(), geolocation=(), payment=(). (2) E-commerce - Allow payment: payment=(self "https://stripe.com"). (3) Video chat - Allow camera/mic: camera=(self), microphone=(self). (4) Banking - Strict everything: Block all unnecessary features. Monitoring: Watch console for violations: "Feature blocked by Permissions Policy", adjust policy if legitimate features blocked. This tool checks your Permissions-Policy configuration for security best practices.
Comprehensive approach to security headers: Phase 1: Audit Current State - Use this security headers analyzer, check security score, identify missing headers, document current configuration. Phase 2: Prioritize by Risk - High priority (implement immediately): X-Content-Type-Options: nosniff (easy, no breakage), X-Frame-Options: DENY or SAMEORIGIN (test for iframe usage), Strict-Transport-Security (if HTTPS ready). Medium priority (plan implementation): Content-Security-Policy in report-only mode, Referrer-Policy: no-referrer-when-downgrade, Permissions-Policy for unused features. Low priority (nice-to-have): Expect-CT (being deprecated), X-XSS-Protection (obsolete, CSP replaces it), X-Permitted-Cross-Domain-Policies. Phase 3: Implementation by Header - (1) Start with easy wins: X-Content-Type-Options: nosniff, X-Frame-Options: SAMEORIGIN, Referrer-Policy: strict-origin-when-cross-origin. Add to web server config: Nginx: add_header X-Content-Type-Options "nosniff" always;, Apache: Header always set X-Content-Type-Options "nosniff", IIS: web.config HTTP headers section. (2) Implement HSTS (if HTTPS ready): Start: Strict-Transport-Security: max-age=300, Test 1-2 weeks, Increase: max-age=31536000; includeSubDomains (after subdomain testing), Consider preload after 6 months. (3) Deploy CSP gradually: Week 1: Report-only with permissive policy, Content-Security-Policy-Report-Only: default-src *; report-uri /csp-report, analyze violations, identify inline scripts/styles. Week 2-4: Refactor inline scripts, move to external .js files, implement nonces or hashes, tighten policy. Week 5: Switch to enforcing, Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-{random}'; report-uri /csp-report, monitor and adjust. (4) Configure Permissions-Policy: Identify features your site uses, block everything else: Permissions-Policy: geolocation=(), camera=(), microphone=(), payment=(), adjust based on needs. Phase 4: Testing - Automated testing: securityheaders.com (online checker), this security headers analyzer, Mozilla Observatory, CI/CD integration (fail build if headers missing). Manual testing: Browser DevTools (check headers in Network tab), test functionality (ensure nothing broken), verify CSP violations (DevTools Console). Phase 5: Monitoring - CSP violation monitoring: Collect reports at /csp-report endpoint, analyze for: legitimate violations (fix policy), attack attempts (investigate), monitor trends over time. Tools: report-uri.com (free CSP monitoring), Sentry (CSP violation tracking), custom logging. Phase 6: Maintenance - Review quarterly, update CSP as site evolves (new features, new CDNs), increase HSTS max-age gradually, monitor browser support for new headers. Configuration by platform: Nginx: \nadd_header X-Content-Type-Options "nosniff" always;\nadd_header X-Frame-Options "SAMEORIGIN" always;\nadd_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;\nadd_header Content-Security-Policy "default-src 'self';" always;\n Apache: \nHeader always set X-Content-Type-Options "nosniff"\nHeader always set X-Frame-Options "SAMEORIGIN"\nHeader always set Strict-Transport-Security "max-age=31536000; includeSubDomains"\nHeader always set Content-Security-Policy "default-src 'self'"\n Express.js (Helmet middleware): javascript\nconst helmet = require('helmet');\napp.use(helmet());\n Django: python\nSECURE_CONTENT_TYPE_NOSNIFF = True\nX_FRAME_OPTIONS = 'SAMEORIGIN'\nSECURE_HSTS_SECONDS = 31536000\nCSP_DEFAULT_SRC = ("'self'",)\n Common pitfalls: (1) Setting headers only on HTML (need on all responses), (2) Conflicting headers (old + new), (3) Not testing in production-like environment, (4) Forgetting to update headers in all environments (dev/staging/prod). Measuring success: Track security score over time (aim for A+ on security scanners), monitor CSP violations (should decrease), zero clickjacking incidents, improved compliance audit results. This tool provides ongoing header analysis and improvement recommendations.
Frequent mistakes in security header implementation: Misconfiguration 1: Headers not sent on all responses - Problem: Only set headers on HTML pages, JSON APIs, static assets (CSS/JS/images) lack headers. Impact: APIs vulnerable without headers, XSS in JSON endpoints. Fix: Set headers globally at web server level (not application code), verify on all content types. Misconfiguration 2: Conflicting header values - Problem: Multiple X-Frame-Options headers: X-Frame-Options: DENY, X-Frame-Options: SAMEORIGIN (both sent). Impact: Browser behavior undefined (might use first, might ignore both). Fix: Remove duplicate header definitions, audit config files for conflicts. Misconfiguration 3: CSP with 'unsafe-inline' or 'unsafe-eval' - Problem: CSP includes: script-src 'self' 'unsafe-inline', defeats XSS protection (inline scripts execute). Impact: CSP provides false sense of security. Fix: Eliminate inline scripts, use nonces: script-src 'self' 'nonce-random123', or hashes for static inline content. Misconfiguration 4: HSTS on HTTP responses - Problem: Sending: Strict-Transport-Security: max-age=31536000 on HTTP (not HTTPS). Impact: Browser ignores HSTS header (HSTS only processes over HTTPS), no protection. Fix: Only send HSTS over HTTPS connections, redirect HTTP to HTTPS first. Misconfiguration 5: includeSubDomains without subdomain SSL - Problem: HSTS: includeSubDomains but some subdomains don't have SSL certificates. Impact: Subdomains become inaccessible (HSTS enforces HTTPS but cert invalid/missing), user sees certificate error and can't bypass. Fix: Ensure ALL subdomains have valid SSL certificates, or don't use includeSubDomains. Misconfiguration 6: Overly permissive CSP - Problem: default-src *; script-src https:;, allows any HTTPS source (defeats purpose). Impact: XSS still possible from attacker-controlled HTTPS domains. Fix: Whitelist specific trusted domains, use 'self' as baseline. Misconfiguration 7: Missing CSP on user-generated content - Problem: Main site has CSP, but user content pages don't (e.g., /user/profile/123). Impact: XSS possible in user content sections. Fix: Ensure CSP applies to ALL pages, especially user-generated content areas. Misconfiguration 8: X-Frame-Options: ALLOW-FROM - Problem: X-Frame-Options: ALLOW-FROM https://partner.com. Impact: Poor browser support (only IE supported it, now deprecated), doesn't work in modern browsers. Fix: Use CSP frame-ancestors: Content-Security-Policy: frame-ancestors https://partner.com. Misconfiguration 9: Setting headers in HTML meta tags - Problem: Using <meta http-equiv="X-Frame-Options" content="DENY">. Impact: Most security headers don't work in meta tags (ignored by browsers), only CSP and Refresh work in meta. Fix: Set headers at HTTP level (web server or application), not in HTML. Misconfiguration 10: Not monitoring CSP violations - Problem: CSP deployed but no report-uri configured, or endpoint doesn't log reports. Impact: Missing attack attempts, can't refine policy based on real usage. Fix: Implement violation reporting: report-uri /csp-report, log and analyze reports, adjust policy accordingly. Misconfiguration 11: Development vs production configs - Problem: Permissive CSP in development, strict in production (or vice versa). Impact: Issues not caught until production, or production not protected. Fix: Keep configs in sync, use environment variables for differences, test production config in staging. Misconfiguration 12: Caching headers prevent updates - Problem: Headers cached by CDN/browser, can't update policy quickly. Impact: Security changes take days/weeks to propagate. Fix: Don't cache security headers aggressively, use short cache times for critical headers, be prepared for gradual rollout. Misconfiguration 13: Incorrect CSP syntax - Problem: script-src 'self' https://cdn.example.com; (semicolon instead of space). Impact: CSP parsing fails, entire policy ignored, no protection. Fix: Validate CSP syntax (use CSP validators), test in browser DevTools, monitor for policy errors. Prevention checklist: (1) Use security header testing tools regularly, (2) Implement in staging first, (3) Monitor for issues after deployment, (4) Document header purposes and configuration, (5) Review quarterly for updates, (6) Train team on proper security header usage. Tools for validation: This security headers analyzer, securityheaders.com, Mozilla Observatory, CSP Evaluator (Google), HSTS preload checker. Recovery from misconfig: If HSTS breaks subdomains: Remove includeSubDomains, send max-age=0 to reset, fix SSL certificates, re-enable. If CSP breaks functionality: Switch to report-only, analyze violations, fix code, re-deploy. This tool helps identify common misconfigurations before they impact users.