Security headers: the browser's first line of defense
HTTP security headers are instructions that the web server sends to the browser along with the response, indicating how to behave to protect the user. Without these headers, the browser applies only its default policies, which are often not sufficient to prevent attacks such as XSS (Cross-Site Scripting), clickjacking, content-type sniffing and HTTPS downgrade. Configuring the correct headers is one of the most effective and least invasive security measures you can implement.
Our Security Headers analyzer checks the presence and correct configuration of every security header, assigning a score and providing specific recommendations. But unlike a simple present/absent check, it also analyzes values: a CSP that is too permissive (unsafe-inline, unsafe-eval) is almost worse than not having one, because it creates a false sense of security.
Essential headers
CSP (Content-Security-Policy) is the most powerful: it defines which resources the browser can load and from where. It effectively prevents XSS attacks by blocking the execution of unauthorized scripts. HSTS (Strict-Transport-Security) forces the browser to always use HTTPS, even if the user types http://. The preload parameter allows the domain to be added to browsers' HSTS preloaded list, ensuring HTTPS from the very first visit.
Practical implementation
Implementation happens at the web server level. On Nginx add add_header in server or location directives. On Apache use Header set in the .htaccess file or virtualhost configuration. If you use a CDN (Cloudflare, AWS CloudFront), you can configure headers directly in the CDN. Always verify the result with our Security Headers check after each change, and test the site to ensure CSP doesn't block legitimate resources.
Combine header checking with SSL Check to verify the SSL certificate and HTTP Headers for a complete analysis of all response headers (not just security ones). A site with perfect HTTPS but without security headers is vulnerable to attacks that HTTPS doesn't prevent (XSS, clickjacking). Conversely, security headers without HTTPS have limited effectiveness. Web security requires both.
The recommended approach is incremental: start with the simplest headers (X-Content-Type-Options, X-Frame-Options), then add HSTS and Referrer-Policy, and finally implement CSP starting from a permissive policy and gradually tightening it while monitoring violations with the report-uri parameter. A CSP that is too restrictive launched without testing can break site functionality, so always test in report-only mode before enforcing.