OWASP Secure Headers Project

Best Practice: OWASP Secure Headers Project

The OWASP Secure Headers Project documents the HTTP response headers that harden web applications and the recommended values for each. These headers tell the browser how to behave safely, for example a Content-Security-Policy limits which scripts can run, Strict-Transport-Security forces HTTPS, and X-Content-Type-Options stops content-type sniffing. It matters because many client-side attacks, such as cross-site scripting and clickjacking, are mitigated cheaply by setting the right headers. The project gives teams a clear, maintained reference instead of guessing which headers to use and how. For a developer it answers exactly which headers to set and to what value; for a leader it is a high-return, low-cost hardening step. Content-Security-Policy is the most powerful and the most error-prone header, which is why it should be rolled out in report-only mode and tightened gradually. The project also maintains a list of headers to remove, not just add, because verbose Server, X-Powered-By, and similar headers tell an attacker exactly what software and version to target. Trimming these alongside adding protective headers is a quick win that reduces the information available for reconnaissance. It is worth understanding that these headers are instructions to the browser, not server-side enforcement, so they protect users running a compliant browser rather than the server itself. They are therefore a complement to input validation and output encoding, not a substitute: a strong Content-Security-Policy reduces the impact of an XSS bug, but the underlying bug should still be fixed in the application code.

Step-by-Step Implementation Guidance

1. Inventory the security headers your application currently sends.
2. Add Strict-Transport-Security to enforce HTTPS connections.
3. Define a Content-Security-Policy, starting in report-only mode to avoid breakage.
4. Set X-Content-Type-Options to nosniff and configure a Referrer-Policy.
5. Use a frame-ancestors directive (or X-Frame-Options) to prevent clickjacking.
6. Remove headers that leak server details, such as verbose Server or X-Powered-By values.
7. Enforce headers centrally at the gateway or framework and test them in CI.

Common Mistakes Teams Make When Ignoring This Practice

• Shipping a permissive or missing Content-Security-Policy that allows inline scripts.
• Enabling HSTS without testing, then locking users out over HTTP.
• Setting headers on some routes but not others.
• Leaking framework and version details through response headers.
• Copying header values from blog posts without understanding the directives.
• Treating headers as set-and-forget and not re-checking them after a framework or CDN upgrade.

Tools and Techniques That Support This Practice

• The OWASP Secure Headers Project reference and recommended values.
• Scanners such as securityheaders.com and Mozilla Observatory.
• OWASP ZAP to verify headers across endpoints.
• Reverse proxies and frameworks to apply headers centrally.
• CSP report endpoints to tune policy before enforcing it.
• Browser developer tools and CSP evaluators to inspect applied headers and policy weaknesses.

How This Practice Applies to Different Migration Types

• Cloud Migration: Re-apply headers at new load balancers, CDNs, or gateways that may strip them.
• Database Migration: Less directly relevant, but confirm admin and reporting UIs over the new data still send headers.
• SaaS Migration: Verify that embedded vendor widgets are compatible with your Content-Security-Policy.
• Codebase Migration: Re-implement header configuration when moving between web frameworks.

Checklist

• Inventoried current security headers
• Enabled Strict-Transport-Security after testing
• Defined a Content-Security-Policy (report-only first)
• Set nosniff and a Referrer-Policy
• Configured anti-clickjacking directives
• Removed server and framework disclosure headers
• Enforced and tested headers centrally