Configure HTTP Security Headers for Web Applications

A skill acting as an expert in HTTP security headers configuration, covering defense against XSS, CSRF, clickjacking, and content injection through properly layered security headers. It documents defense-in-depth principles (layering multiple headers at both web-server and application levels, progressive enhancement starting permissive and tightening over time, testing in report-only mode before enforcement) and browser-compatibility considerations (understanding directive support, fallbacks for older browsers, mobile limitations). It provides concrete configuration for the essential headers: Content-Security-Policy (a basic policy plus a progressive report-only-then-strict rollout), X-Frame-Options versus the modern CSP frame-ancestors directive for clickjacking prevention, and Strict-Transport-Security including the preload flag. It gives working configuration examples across five layers: Nginx add_header blocks, Apache Header directives (including unsetting Server and X-Powered-By to remove server fingerprinting), Express.js via the Helmet middleware, Django settings.py (SECURE_* and CSP_* settings), and a CSP violation-report endpoint that logs blocked-uri and violated-directive fields from incoming reports. It also covers testing headers with curl and public tools (securityheaders.com, observatory.mozilla.org, hstspreload.org), a CSP rollout strategy (report-only first, monitor violations for 1-2 weeks, tighten gradually, prefer nonces over unsafe-inline/unsafe-eval), performance tips (minimize header size, strict-dynamic, unsafe-hashes over unsafe-inline), common pitfalls (conflicting X-Frame-Options vs CSP frame-ancestors, HSTS preload risk, includeSubDomains implications), and environment-specific CSP examples for development, staging, and production.

Use it when configuring or hardening HTTP security headers for a web application - implementing CSP, HSTS, clickjacking protection, or setting up violation reporting - at the web-server, framework, or application level. It also covers removing server-fingerprinting headers like Server and X-Powered-By, and choosing between X-Frame-Options and the more modern CSP frame-ancestors directive for the same clickjacking-prevention goal.

Given a web application's stack (Nginx, Apache, Express.js, or Django) and security requirements, it produces working header configuration blocks, a CSP rollout plan, and a violation-reporting endpoint implementation.

Configuration for Nginx and Apache web servers, the Helmet middleware for Express.js, and Django's built-in SECURE_* and CSP_* settings - plus curl and third-party header-testing services (securityheaders.com, observatory.mozilla.org, hstspreload.org) for validation.

Web developers and security engineers hardening an application's HTTP response headers who want copy-pasteable, environment-aware configuration (development, staging, production) across common web servers and frameworks, plus a safe, monitored rollout strategy for tightening CSP without breaking legitimate resources - starting in report-only mode, watching violation reports for one to two weeks, and only then moving to full enforcement.