Web Security EssentialsLesson 6.3

Security headers every web application needs

Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, Strict-Transport-Security, clickjacking protection

Security Headers That Matter

Security headers are enforced by the browser, not your application code. A single server configuration change activates them site-wide. They provide defense-in-depth — limiting damage even when application-layer vulnerabilities exist.

The essential set

# Blocks your page from being embedded in iframes on other origins (clickjacking)
X-Frame-Options: DENY

# Preferred CSP equivalent — more flexible than X-Frame-Options
Content-Security-Policy: frame-ancestors 'none'

# Browser must use declared Content-Type — disables MIME sniffing attacks
X-Content-Type-Options: nosniff

# Controls how much of your URL leaks in the Referer header on navigation
Referrer-Policy: strict-origin-when-cross-origin

# Disable browser features your app never uses
Permissions-Policy: camera=(), microphone=(), geolocation=()

# Forces HTTPS for all future connections (see TLS module)
Strict-Transport-Security: max-age=31536000; includeSubDomains

Content-Security-Policy in depth

CSP is the most powerful header. It whitelists the exact sources allowed to load scripts, styles, images, and fonts. A strict policy blocks XSS execution even after injection:

Content-Security-Policy:
  default-src 'self';
  script-src 'self' https://cdn.example.com;
  style-src 'self' 'unsafe-inline';
  img-src 'self' data: https:;
  frame-ancestors 'none'

Deploy gradually. Start with the report-only mode to audit violations without breaking functionality — then tighten the policy once you understand what your pages legitimately load:

# Audit mode — logs violations, does not block
Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-report