Security Headers Analyzer

`, 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."}}]}