Analyze your website's HTTP security headers. Checks for CSP, HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, and Permissions-Policy — the headers that protect against XSS, clickjacking, and information disclosure.
This tool checks one area. The full scan covers SSL, open ports, HTTP headers, breach exposure, subdomain enumeration, compliance mapping, and more — free, no login required.
HTTP security headers are directives sent by your web server in HTTP responses that instruct browsers to enable specific security features. They act as a second line of defense — even if your application code has vulnerabilities, properly configured security headers can prevent attackers from exploiting them. Security headers are free to implement, require no code changes, and provide significant protection against common web attacks including cross-site scripting (XSS), clickjacking, MIME sniffing, and protocol downgrade attacks.
Despite their effectiveness and low implementation cost, security headers remain one of the most overlooked aspects of web security. Many production websites are missing critical headers entirely, leaving their users exposed to attacks that would otherwise be blocked by a few lines of server configuration.
The following table lists the security headers every website should implement, along with their function and recommended configuration.
| Header | Purpose | Recommended Value |
|---|---|---|
| Strict-Transport-Security | Forces HTTPS connections, prevents downgrade attacks | max-age=31536000; includeSubDomains; preload |
| Content-Security-Policy | Prevents XSS by controlling resource loading | default-src 'self'; script-src 'self' |
| X-Content-Type-Options | Prevents MIME type sniffing | nosniff |
| X-Frame-Options | Prevents clickjacking via iframes | DENY or SAMEORIGIN |
| Referrer-Policy | Controls referrer information leakage | strict-origin-when-cross-origin |
| Permissions-Policy | Controls browser feature access (camera, mic, geolocation) | camera=(), microphone=(), geolocation=() |
| X-XSS-Protection | Legacy XSS filter (deprecated in modern browsers) | 0 (CSP is the modern replacement) |
HSTS tells browsers to only connect to your site over HTTPS, even if the user types http:// in the address bar. This prevents protocol downgrade attacks where an attacker intercepts the initial HTTP request before the server can redirect to HTTPS. The max-age directive specifies how long browsers should remember this policy (31536000 seconds = 1 year). Adding includeSubDomains extends the policy to all subdomains, and preload allows your domain to be hardcoded into browser HSTS preload lists for protection on the very first visit.
CSP is the most powerful security header available. It defines an allowlist of content sources for your page, telling the browser exactly which scripts, stylesheets, images, fonts, and other resources are permitted to load. If an attacker injects a malicious script tag through an XSS vulnerability, the browser blocks it because the script's origin is not in the CSP allowlist. Start with a restrictive policy like default-src 'self' and gradually add exceptions as needed. Use Content-Security-Policy-Report-Only to test your policy without breaking functionality.
Setting this header to nosniff prevents browsers from MIME-type sniffing — a behavior where the browser ignores the declared content type and tries to determine the type by inspecting the content. Attackers exploit this by uploading files with misleading extensions that execute as scripts when sniffed. This is a single-value header with no configuration complexity.
This header prevents your site from being embedded in iframes on other domains, which is the primary mechanism for clickjacking attacks. In a clickjacking attack, an attacker overlays your site with invisible iframes, tricking users into clicking buttons they cannot see. Set to DENY to block all framing, or SAMEORIGIN if your site uses iframes internally. The modern replacement is CSP's frame-ancestors directive, but X-Frame-Options should still be set for older browser compatibility.
Controls how much referrer information is included when navigating away from your site. Without this header, the full URL (including query parameters that may contain tokens, session IDs, or personal data) can leak to third-party sites. The recommended value strict-origin-when-cross-origin sends the full URL for same-origin requests but only the origin for cross-origin requests, and sends nothing when downgrading from HTTPS to HTTP.
Formerly known as Feature-Policy, this header controls which browser features (camera, microphone, geolocation, payment, USB, etc.) your site and embedded iframes are allowed to use. By explicitly disabling features you do not use, you prevent malicious scripts from accessing sensitive device capabilities even if they manage to execute on your page.
Without HSTS, even sites that redirect HTTP to HTTPS are vulnerable during the first request. An attacker on the same network can intercept the initial HTTP request, strip the redirect, and serve a plain HTTP version of the site to the victim. HSTS eliminates this window entirely.
Sites without CSP have no browser-level protection against XSS. Any successful script injection will execute with full page privileges, allowing attackers to steal cookies, capture keystrokes, redirect users, or modify page content. CSP is the single most effective mitigation for XSS vulnerabilities.
While not strictly a security header, the Access-Control-Allow-Origin header is frequently misconfigured. Setting it to * allows any website to make authenticated requests to your API, potentially exposing sensitive data. Always restrict CORS to specific, trusted origins.
Without nosniff, browsers may execute uploaded files as JavaScript even if they are served with an incorrect content type. This is especially dangerous on sites that accept user uploads, as an attacker can upload a file disguised as an image that the browser executes as a script.
Security headers are added at the web server or CDN level and require no application code changes. The implementation varies by platform:
Nginx: Use the add_header directive in your server or location blocks. Apache: Use the Header set directive in your .htaccess or virtual host configuration. Cloudflare: Configure headers through Transform Rules or Workers. AWS CloudFront: Use response headers policies or Lambda@Edge functions. Most CDN providers offer built-in security header configuration through their dashboards, making it possible to add all recommended headers without touching your origin server.
When you enter a domain, our HTTP Security Headers Checker makes an HTTPS request to your site and inspects the response headers. Each security header is evaluated against current best practices and assigned a pass, warning, or fail status. Missing headers are flagged with specific remediation steps, and misconfigured headers receive detailed guidance on how to correct them.
The checker evaluates both the presence and the quality of each header. For example, an HSTS header with a short max-age value will trigger a warning, even though the header is technically present. Similarly, a CSP that uses unsafe-inline or unsafe-eval will be flagged as weakening the policy. For a complete security assessment including SSL/TLS configuration and DNS security, run a full domain security scan.
Security headers have negligible impact on performance. They are small text strings added to HTTP responses and add only a few bytes to each response. The browser processing overhead is minimal. In fact, some headers like Content-Security-Policy can improve perceived performance by preventing unnecessary resource loads from unauthorized origins. HSTS can also improve performance by eliminating the initial HTTP-to-HTTPS redirect for returning visitors.
Content-Security-Policy (CSP) is widely considered the most impactful security header because it provides robust protection against cross-site scripting (XSS), the most common web vulnerability. A well-configured CSP restricts which scripts, styles, and resources can load on your pages, effectively neutralizing most XSS attacks even if an attacker finds an injection point. Strict-Transport-Security (HSTS) is a close second, as it prevents protocol downgrade attacks and cookie hijacking.
For production websites, yes — you should implement all recommended security headers. Each header protects against a different attack vector, and omitting any one of them leaves a gap in your defenses. The effort to implement them is minimal (a few lines of server configuration), while the protection they provide is significant. At minimum, every site should have HSTS, CSP, X-Content-Type-Options, and X-Frame-Options.
Use the free HTTP Security Headers Checker above to scan your domain instantly. The tool fetches your site's HTTP response headers, evaluates each security header against best practices, and provides a grade along with specific remediation guidance. You can also inspect headers manually using browser developer tools (Network tab) or command-line tools like curl with the -I flag. For continuous monitoring, consider setting up automated scans through our platform.