Security Headers Audit

This skill performs static code analysis for HTTP security header misconfigurations across Express/Helmet.js, Nginx, Apache, Next.js, Flask, Django, and Spring Boot projects. HTTP response headers are the first line of defence against a wide class of client-side attacks — clickjacking, MIME-sniffing, cross-site scripting amplification, cross-origin data leakage, and protocol downgrade attacks. A single missing or misconfigured header can expose users to attacks that a compliant browser would otherwise block. This skill audits 10+ header-level controls, maps each finding to CWE and OWASP Top 10:2021 identifiers, and produces UNSAFE/SAFE code pairs across multiple frameworks so developers can apply fixes immediately.

When to Use

• When the user asks to "audit security headers", "check HTTP headers", "review header config", or "harden web headers"
• When the user mentions "CSP", "Content-Security-Policy", "unsafe-inline", "unsafe-eval", or "CSP report-only"
• When the user asks about "CORS", "Access-Control-Allow-Origin", or "cross-origin policy"
• When the user asks about "HSTS", "Strict-Transport-Security", "HTTPS enforcement", or "preload"
• When the user asks about "X-Frame-Options", "clickjacking protection", or "frame-ancestors"
• When the user asks about "X-Content-Type-Options", "MIME sniffing", or "nosniff"
• When the user asks about "Referrer-Policy", "Permissions-Policy", or "Feature-Policy"
• When reviewing Express middleware, Nginx server blocks, Apache VirtualHost configs, Flask response objects, or Spring Boot security config
• When preparing a web application for a security audit, penetration test, or compliance review (PCI-DSS, HIPAA, FedRAMP)
• When a pull request modifies server configuration, middleware stacks, or HTTP response handling

When NOT to Use