HTTP Security Headers Explained

HTTP security headers are directives sent by your web server that instruct browsers how to behave when handling your website's content. They prevent entire categories of attacks — cross-site scripting (XSS), clickjacking, MIME sniffing, protocol downgrade, and data injection — without requiring changes to your application code. Security headers are one of the highest-impact, lowest-effort security improvements you can make. They are configured at the web server or CDN level and apply to every page of your site. Once configured, they provide passive, continuous protection. Despite their effectiveness, most SMB websites are missing critical security headers. Studies consistently find that over 70% of websites lack a Content Security Policy, and over 50% are missing HSTS. Cyber Defense Agent scans for missing security headers: Every CDA scan checks your website for the presence and correct configuration of essential security headers. Missing or misconfigured headers are flagged in your Cyber Defense Score with specific remediation guidance. Compliance frameworks and security headers: - PCI DSS v4.0: Requirement 6.4.3 requires Content Security Policy for payment pages. - OWASP Top 10: Security misconfiguration (including missing headers) is consistently in the Top 10. - CIS Benchmarks: Web server benchmarks include security header configuration. - Cyber insurance: Carriers that scan applicant domains check for security headers as indicators of security maturity. Implementing the four critical security headers below will prevent the majority of client-side web attacks and improve your security posture score.

Content Security Policy is the most powerful security header. It controls which resources (scripts, styles, images, fonts, frames) the browser is allowed to load on your page. CSP prevents cross-site scripting (XSS) attacks by blocking unauthorized script execution. How CSP prevents XSS: Without CSP, if an attacker injects a script tag into your page (through a form input, URL parameter, or stored XSS vulnerability), the browser executes it without question. With CSP, the browser checks every resource load against your policy. If the script is not from an approved source, the browser blocks it. CSP directives: - default-src: Fallback policy for all resource types not explicitly defined. - script-src: Controls which scripts can execute. The most critical directive. - style-src: Controls which stylesheets can load. - img-src: Controls which images can load. - font-src: Controls which fonts can load. - connect-src: Controls which URLs JavaScript can fetch/XMLHttpRequest. - frame-src: Controls which URLs can be loaded in iframes. - frame-ancestors: Controls which sites can embed your page in an iframe (replaces X-Frame-Options). - report-uri / report-to: URL where the browser sends violation reports. Implementation strategy: 1. Start with report-only mode: Use Content-Security-Policy-Report-Only to monitor what would be blocked without actually blocking anything. Analyze reports for 2-4 weeks. 2. Build your policy: Based on reports, identify all legitimate resource sources. Create an allowlist policy. 3. Example CSP for a typical SMB website: Content-Security-Policy: default-src 'self'; script-src 'self' https://www.googletagmanager.com https://www.google-analytics.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' https://fonts.gstatic.com; frame-ancestors 'none'; base-uri 'self'; form-action 'self'; 4. Avoid unsafe-inline for scripts: The 'unsafe-inline' directive for script-src largely defeats the purpose of CSP. Use nonces or hashes instead to allow specific inline scripts. 5. Deploy and monitor: Enable the full policy (not report-only) and continue monitoring violation reports. Adjust as you add new features or third-party integrations.

HTTP Strict Transport Security (HSTS): HSTS tells browsers to only connect to your site over HTTPS — never HTTP. Once a browser receives the HSTS header, it automatically upgrades all future HTTP requests to HTTPS, even if the user types http:// or clicks an HTTP link. Why HSTS matters: Without HSTS, the initial HTTP request (before the redirect to HTTPS) is vulnerable to man-in-the-middle attacks. An attacker can intercept this unencrypted request and strip the HTTPS redirect (SSL stripping attack). Implementation: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload - max-age=31536000: Browser remembers the HTTPS-only policy for one year. - includeSubDomains: Applies to all subdomains. - preload: Allows submission to the HSTS preload list (hstspreload.org), which hardcodes your domain as HTTPS-only in browsers. IMPORTANT: Before enabling includeSubDomains, verify all subdomains support HTTPS. A subdomain without HTTPS will become unreachable. X-Frame-Options: X-Frame-Options prevents your website from being embedded in iframes on other sites. This prevents clickjacking attacks, where an attacker overlays your site with an invisible iframe to trick users into clicking buttons they cannot see. Options: - X-Frame-Options: DENY — No framing allowed. Use this unless you specifically need framing. - X-Frame-Options: SAMEORIGIN — Only your own domain can frame your pages. Note: CSP frame-ancestors directive is the modern replacement for X-Frame-Options and is more flexible. Use both for maximum compatibility. X-Content-Type-Options: X-Content-Type-Options: nosniff prevents browsers from MIME-sniffing a response away from the declared Content-Type. Without this header, browsers may interpret a file differently than intended — for example, treating a text file as JavaScript and executing it. Implementation: X-Content-Type-Options: nosniff This is a simple, universal header with no configuration needed. There is no reason not to include it on every response. Additional recommended headers: - Referrer-Policy: strict-origin-when-cross-origin — Controls how much referrer information is sent with requests. Prevents leaking internal URLs to external sites. - Permissions-Policy: camera=(), microphone=(), geolocation=() — Restricts browser features your site does not use, preventing potential abuse by injected scripts. - X-DNS-Prefetch-Control: off — Prevents the browser from performing DNS lookups for links on your page, which can leak browsing behavior.

Security headers can be configured at multiple levels. Choose the approach that fits your infrastructure: Web server configuration: Nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; frame-ancestors 'none';" always; add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always; add_header X-Frame-Options "DENY" always; add_header X-Content-Type-Options "nosniff" always; add_header Referrer-Policy "strict-origin-when-cross-origin" always; add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always; Apache (.htaccess or httpd.conf): Header always set Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; frame-ancestors 'none'" Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" Header always set X-Frame-Options "DENY" Header always set X-Content-Type-Options "nosniff" Header always set Referrer-Policy "strict-origin-when-cross-origin" Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()" CDN and cloud platform configuration: - Cloudflare: Security headers can be configured via Transform Rules or Cloudflare Workers. HSTS has a dedicated toggle in the SSL/TLS settings. - AWS CloudFront: Use response headers policies to add security headers to all responses. - Vercel: Configure headers in vercel.json or next.config.js for Next.js applications. - Netlify: Configure headers in the _headers file or netlify.toml. Application framework configuration: - Next.js: Configure headers in next.config.js using the headers() function. - Express.js: Use the helmet middleware — it configures all essential security headers with sensible defaults. - Django: Use django-csp and SecurityMiddleware for comprehensive header configuration. - WordPress: Use the Headers Security Advanced & HSTS WP plugin or configure in .htaccess. CDA security header verification: Cyber Defense Agent checks for the presence and configuration of security headers in every scan: - Content-Security-Policy: Present? Overly permissive (unsafe-inline, unsafe-eval)? - Strict-Transport-Security: Present? Adequate max-age? includeSubDomains? - X-Frame-Options: Present? Set to DENY or SAMEORIGIN? - X-Content-Type-Options: Present? Set to nosniff? - Referrer-Policy: Present? Configured appropriately? - Permissions-Policy: Present? Restricting unnecessary features? Missing headers are flagged as findings in your Cyber Defense Score. CDA provides the specific header values you need to add, making remediation straightforward. Testing your headers: After configuration, verify your headers using: - securityheaders.com: Free online scanner that grades your security headers (A+ to F). - Mozilla Observatory: Comprehensive web security scanner including headers. - Browser DevTools: Network tab shows all response headers for manual verification. - CDA re-scan: Run a follow-up Cyber Defense Agent scan to verify your score improvement.