Content Security Policy headers (defense-in-depth)

400 views

                  import type { RequestHandler } from 'express';

export const csp: RequestHandler = (_req, res, next) => {
  const policy = [
    "default-src 'self'",
    "base-uri 'self'",
    "object-src 'none'",
    "frame-ancestors 'none'",
    "img-src 'self' data:",
    "style-src 'self' 'unsafe-inline'", // tighten later if you can
    "script-src 'self'"
  ].join('; ');

  res.setHeader('Content-Security-Policy', policy);
  next();
};

XSS is still the most common ‘we didn’t think about it’ vulnerability in web apps. A Content-Security-Policy doesn’t replace sanitization, but it dramatically reduces blast radius when something slips through. I start from a strict baseline (no inline scripts), then loosen only what I can justify. For third-party scripts, I prefer nonce-based policies over permanently whitelisting every CDN domain. I also ship CSP in report-only mode first so I can iterate without breaking production, then enforce once I’m confident. It’s slow to set up once, but it pays dividends by preventing whole categories of issues and making future regressions much harder.

Mateo Rodriguez

More from Mateo Rodriguez

Content Security Policy headers (defense-in-depth)

0 Comments

More from Mateo Rodriguez