Most website owners focus on firewalls, password policies, and patching schedules, but they ignore a small yet powerful layer of protection sent with every page load: HTTP security headers. A security header check reveals whether your site instructs browsers to enforce HTTPS, block malicious scripts, restrict embedding, and prevent data leakage. One missing or misconfigured header can leave visitors exposed to clickjacking, MIME sniffing, session hijacking, or cross-site scripting even when the rest of your infrastructure looks solid.
What Is a Security Header Check and Why Does It Matter?
Security headers are HTTP response headers that tell a browser how to handle a page’s content and connection. A security header check is an automated or manual review of those headers against security best practices. It examines whether headers like HTTP Strict Transport Security (HSTS), Content Security Policy (CSP), X-Frame-Options, X-Content-Type-Options, Referrer-Policy, and Permissions-Policy are present, correctly configured, and free of dangerous misconfigurations.
Browsers do not enable these protections by default. If a header is missing, the browser simply proceeds without that security layer. Without a proper security header check, a site can have a valid SSL certificate and still be vulnerable to attacks that occur inside the user’s browser rather than on the server. For example, if X-Frame-Options or CSP frame-ancestors is absent, an attacker can load the site in an invisible iframe and trick users into clicking buttons they never intended to click. If X-Content-Type-Options is missing, older browsers may interpret a harmless text file as executable JavaScript, leading to code execution. A reliable header check catches these silent gaps before they become an incident.
The impact goes beyond technical security. Third-party risk assessments, cyber insurance applications, and client security questionnaires increasingly ask about security headers. A poor header score can raise red flags, delay contracts, or increase insurance premiums. Search engines and browsers may also flag poorly configured sites, hurting credibility and user trust. Running a security header check gives you a clear, prioritized view of what to fix before attackers or evaluators discover the weakness.
A thorough security header check evaluates not just presence but also quality. For example, HSTS with a max-age of only a few days provides minimal protection, while a CSP that includes unsafe-inline or unsafe-eval can undermine the entire policy. The check should also detect duplicate headers, syntax errors, and contradictions, such as HSTS missing includeSubDomains on a site where subdomains handle authentication. The result is not only a list of missing headers but also a risk score and actionable recommendations.
Critical Security Headers Every Check Should Validate
HTTP Strict Transport Security (HSTS) forces browsers to connect exclusively over HTTPS for a specified period. Without it, users may start with an insecure HTTP request before being redirected, creating a window for a man-in-the-middle to intercept credentials or inject content. A security header check should verify that HSTS is present, uses a sufficiently long max-age such as 31536000 seconds, includes includeSubDomains, and ideally supports the preload list. Misconfigurations like setting max-age to zero or missing subdomain coverage can leave the main site and its services exposed.
Content Security Policy (CSP) is one of the most powerful headers for preventing cross-site scripting and data injection. It tells the browser which scripts, styles, images, and endpoints are allowed. A weak CSP may contain overly broad directives such as * for script-src or default-src, or the keywords unsafe-inline and unsafe-eval, which significantly reduce protection. A meaningful security header check should parse the CSP, flag unsafe sources, advise moving inline scripts to external files, and recommend frame-ancestors instead of relying solely on X-Frame-Options.
X-Frame-Options controls whether the page can be embedded in frames. Valid values are DENY or SAMEORIGIN. X-Content-Type-Options: nosniff stops browsers from guessing MIME types and ensures they interpret content only as declared. Referrer-Policy limits how much URL information is passed to third parties; overly permissive values can leak sensitive tokens or account identifiers from the query string. Permissions-Policy restricts browser features like camera, microphone, geolocation, and payment APIs from being abused by scripts. Each of these headers is small but important and should be checked for both presence and syntax.
While not strictly response headers, cookie attributes are sent in the Set-Cookie header and directly affect session security. A security header check that includes cookie analysis can flag cookies missing the Secure flag, HttpOnly flag, or SameSite policy. A session cookie sent without Secure over HTTP can be intercepted, and without HttpOnly it can be read by JavaScript if an XSS flaw appears. A SameSite value of Lax or Strict reduces cross-site request forgery risk. Validating these attributes turns a header check into a more complete browser-security audit.
How to Run a Security Header Check and Act on the Results
You can start by opening your site in a browser, opening developer tools, and inspecting the Network tab. Look at the response headers for the main document. Alternatively, run curl -I https://yourdomain.com from a command line. This shows raw headers, but manually interpreting them across dozens of pages, subdomains, and third-party services is time-consuming and error-prone. A missing header on a checkout page may be more critical than on a blog post, and a single scan of the homepage may not reflect application-wide risk.
A dedicated security header check automates this work by scanning the headers, grading each one against current standards, and turning the results into a simple security score. The scan should also monitor continuously and alert when a deployment or CDN change accidentally removes a header. Many organizations pass a one-time check only to have a marketing tag, plugin update, or server migration silently weaken the policy later.
Once the check identifies a failure, fixes usually happen at the server, CDN, or application level. For Nginx, an HSTS header can be added with add_header Strict-Transport-Security “max-age=31536000; includeSubDomains” always;. Apache uses a similar Header directive. If your site sits behind Cloudflare or another CDN, you can often enable HSTS and other headers in the dashboard. CSP often requires more planning: inventory every script, style, image, and API endpoint, then build a policy that allows only those origins. Use Content-Security-Policy-Report-Only first to collect violation reports without breaking functionality, then enforce the policy after testing.
A security header check should also help you prioritize. Start with headers that prevent credential theft and session hijacking: HSTS, cookies with Secure and HttpOnly, and X-Content-Type-Options. Then add X-Frame-Options or CSP frame-ancestors to prevent clickjacking. Finally, roll out a tailored CSP and Permissions-Policy to reduce the blast radius of injected scripts. After each change, rerun the check to verify the header appears correctly and no conflicting duplicate headers exist. Use shareable reports to communicate progress to developers, marketing teams, and auditors, so security does not remain an invisible technical detail but becomes a measurable part of your site’s health.
