HTTP security headers are response headers that instruct browsers to enforce security policies, protecting web applications from attacks like XSS, clickjacking, and data injection.
HTTP security headers are directives sent in server responses that instruct browsers to enforce specific security policies. They protect against client-side attacks including cross-site scripting, clickjacking, MIME type sniffing, and protocol downgrade attacks. Properly configured security headers provide a defense layer that operates within the browser, complementing server-side security controls.
Content-Security-Policy is a powerful header that restricts which resources a browser can load, effectively mitigating cross-site scripting and data injection attacks. CSP defines allowed sources for scripts, styles, images, fonts, and other content types. A strict CSP policy significantly reduces XSS impact even when injection vulnerabilities exist in the application code itself.
HTTP Strict-Transport-Security instructs browsers to only communicate with the server over HTTPS, preventing protocol downgrade attacks and cookie hijacking. Once a browser receives an HSTS header, it automatically converts all HTTP requests to HTTPS for the specified duration. The preload directive allows domains to be hardcoded into browser HSTS lists for protection from the first visit.
Essential headers include Content-Security-Policy to prevent XSS, Strict-Transport-Security to enforce HTTPS, X-Content-Type-Options to prevent MIME sniffing, X-Frame-Options or CSP frame-ancestors to block clickjacking, Referrer-Policy to control information leakage, and Permissions-Policy to restrict browser feature access. Each header addresses specific attack vectors with minimal implementation effort.
Testers inspect response headers for missing or misconfigured security directives, test CSP bypass techniques, verify HSTS deployment including preload status, and assess cookie security attributes. They check for information disclosure through server version headers and evaluate whether header configurations align with application functionality. Tools like SecurityHeaders.com provide initial automated assessment.
Common CSP mistakes include using unsafe-inline and unsafe-eval directives that undermine XSS protection, overly broad source whitelists that include CDN domains hosting user-controlled content, missing default-src fallback directives, and report-only mode deployed permanently without enforcement. Improperly configured CSP creates a false sense of security while providing minimal actual protection.
Modern frameworks like React, Angular, and Next.js require careful CSP configuration to accommodate their rendering approaches. Single-page applications that use inline scripts need nonce-based CSP policies rather than blanket unsafe-inline directives. Framework middleware and server configuration must coordinate to apply headers consistently across all response types including API endpoints.
Permissions-Policy, formerly Feature-Policy, controls which browser features a web application and its embedded content can access. It restricts capabilities like camera, microphone, geolocation, payment APIs, and autoplay. This header limits the damage from XSS by preventing injected scripts from accessing sensitive browser features, and controls functionality available to embedded third-party content.