Content Security Policy (CSP) and Modern HTTP Security Headers: The Implementation Guide

Why HTTP Security Headers are Vital for Web Defense#

HTTP security headers are directive instructions returned by the web server in HTTP response packets. They instruct the user’s web browser on how to handle the page content, which external origins can execute scripts, whether the page may be embedded inside iframes, and how referrer telemetry is shared.

Even if an attacker discovers an injection vulnerability in your application code, a properly configured Content Security Policy prevents the injected malicious payload from executing or sending stolen tokens to an external command-and-control server.

Content Security Policy (CSP): Architecture and Directives#

Content Security Policy (CSP Level 3) allows site administrators to declare an allowlist of trusted sources for scripts, styles, images, fonts, media, and connections.

The Essential Security Headers Suite: HSTS, XFO, and RP#

Beyond CSP, production web servers should return these five standard security headers with every response:

• Strict-Transport-Security (HSTS): Forces browsers to communicate exclusively over HTTPS for a specified timeframe (`max-age=63072000; includeSubDomains; preload`), preventing SSL stripping attacks.
• X-Content-Type-Options: Set to `nosniff` to prevent browsers from MIME-sniffing responses away from the declared Content-Type.
• X-Frame-Options: Set to `DENY` or `SAMEORIGIN` to block malicious websites from embedding your pages in invisible iframes to execute clickjacking attacks.
• Referrer-Policy: Set to `strict-origin-when-cross-origin` to prevent private URL query parameters from leaking to third-party domains in Referer request headers.
• Permissions-Policy: Restricts browser device APIs (e.g. `camera=(), microphone=(), geolocation=()`).

Configuring CSP for Third-Party Scripts (AdSense & Analytics)#

Content-driven websites that monetize through Google AdSense or track traffic via Google Analytics must carefully configure their CSP headers to permit necessary ad frames and telemetry beacons without opening broad security holes.

Content-Security-Policy: 
  default-src 'self';
  script-src 'self' 'unsafe-inline' https://pagead2.googlesyndication.com https://www.googletagmanager.com;
  style-src 'self' 'unsafe-inline' https://fonts.googleapis.com;
  img-src 'self' data: https:;
  font-src 'self' https://fonts.gstatic.com;
  connect-src 'self' https://www.google-analytics.com https://pagead2.googlesyndication.com;
  frame-src https://googleads.g.doubleclick.net https://pagead2.googlesyndication.com;
  object-src 'none';
  base-uri 'self';
  frame-ancestors 'self';

Testing CSP with Report-Only Mode before Enforcement#

Deploying a strict CSP without testing can inadvertently break legitimate functionality. To test safely, use the `Content-Security-Policy-Report-Only` header along with a `report-to` or `report-uri` endpoint.

In Report-Only mode, the browser logs violations to your reporting server and browser console without blocking any resource loading. Once you verify that zero legitimate scripts are flagged, switch the header to active enforcement.

Frequently Asked Questions about Security Headers#

Answers to common web security questions:

• Can CSP replace input sanitization? No. CSP is a defense-in-depth mitigation. You must still escape output and sanitize user inputs.
• What is a CSP nonce? A nonce is a cryptographically random, single-use token generated per request that permits specific inline `<script>` tags while blocking all unauthorized inline scripts.
• Does HSTS affect local development? Only if you configure `includeSubDomains` on a root domain that shares localhost subdomains; use distinct domain names for local environments.