`, 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."}},{"@type":"Question","name":"What is Permissions-Policy and how does it enhance security?","acceptedAnswer":{"@type":"Answer","text":"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: ``, 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: ``, 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."}},{"@type":"Question","name":"How do I implement a security header strategy for my application?","acceptedAnswer":{"@type":"Answer","text":"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."}},{"@type":"Question","name":"What are the common security header misconfigurations and how do I avoid them?","acceptedAnswer":{"@type":"Answer","text":"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 ``. **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."}}]}

Home/Tools/Security/Security Headers Analyzer

Security Headers Analyzer

Analyze HTTP security headers including CSP, HSTS, X-Frame-Options. Get security grade and recommendations for web application hardening.

Loading Security Headers Analyzer...

Input Mode

Website URL

Raw Headers

Loading interactive tool...

JavaScript Required

This interactive tool requires JavaScript to function. Please enable JavaScript in your browser to use the full features.

The tool description and documentation above provide information about this tool's capabilities. For the best experience, please enable JavaScript and refresh the page.

Need Professional Security Services?

Our cybersecurity experts can help protect your business with comprehensive security solutions.

Get Security Assessment View Services

References & Citations

IETF. (2013). RFC 7034: HTTP Header Field X-Frame-Options. Retrieved from https://datatracker.ietf.org/doc/html/rfc7034 (accessed January 2025)
W3C. (2024). Content Security Policy Level 3. Retrieved from https://www.w3.org/TR/CSP3/ (accessed January 2025)
IETF. (2012). RFC 6797: HTTP Strict Transport Security (HSTS). Retrieved from https://datatracker.ietf.org/doc/html/rfc6797 (accessed January 2025)
OWASP. (2024). OWASP Secure Headers Project. Retrieved from https://owasp.org/www-project-secure-headers/ (accessed January 2025)

Note: These citations are provided for informational and educational purposes. Always verify information with the original sources and consult with qualified professionals for specific advice related to your situation.

Frequently Asked Questions

Common questions about the Security Headers Analyzer

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.

⚠️ Security Notice

This tool is provided for educational and authorized security testing purposes only. Always ensure you have proper authorization before testing any systems or networks you do not own. Unauthorized access or security testing may be illegal in your jurisdiction. All processing happens client-side in your browser - no data is sent to our servers.