Security Headers Configuration

Security Headers Configuration

Table of Contents

• Overview
• When to Use
• Quick Start
• Reference Guides
• Best Practices

Overview

Implement comprehensive HTTP security headers to protect web applications from XSS, clickjacking, MIME sniffing, and other browser-based attacks.

When to Use

• New web application deployment
• Security audit remediation
• Compliance requirements
• Browser security hardening
• API security
• Static site protection

Quick Start

Minimal working example:

// security-headers.js
const helmet = require("helmet");

function configureSecurityHeaders(app) {
  // Comprehensive Helmet configuration
  app.use(
    helmet({
      // Content Security Policy
      contentSecurityPolicy: {
        directives: {
          defaultSrc: ["'self'"],
          scriptSrc: [
            "'self'",
            "'unsafe-inline'", // Remove in production
            "https://cdn.example.com",
            "https://www.google-analytics.com",
          ],
          styleSrc: [
            "'self'",
            "'unsafe-inline'",
            "https://fonts.googleapis.com",
          ],
          fontSrc: ["'self'", "https://fonts.gstatic.com"],
          imgSrc: ["'self'", "data:", "https:", "blob:"],
          connectSrc: ["'self'", "https://api.example.com"],
// ... (see reference guides for full implementation)

Reference Guides

Detailed implementations in the references/ directory:

Best Practices

✅ DO

• Use HTTPS everywhere
• Implement strict CSP
• Enable HSTS with preload
• Block framing with X-Frame-Options
• Prevent MIME sniffing
• Report CSP violations
• Test headers regularly
• Use security scanners

❌ DON'T

• Allow unsafe-inline in CSP
• Skip HSTS on subdomains
• Ignore CSP violations
• Use overly permissive policies
• Forget to test changes