How to Check Security Headers for a Website
Security headers tell browsers how to behave when loading your website. Most sites are missing at least a few. Here is what they are, why they matter, and the fastest way to find out where yours stand.
When a browser loads a website, the web server does not just send back HTML. It also sends a collection of instructions called HTTP response headers that tell the browser how to handle the page. Most of those headers deal with caching and content types. A smaller group controls security. These are security headers, and they are one of the most commonly overlooked parts of a website's defenses.
Browsers cannot enforce protections that were never declared. Without security headers, common attacks go unchecked, not because they are sophisticated, but because the browser was never told to block them. This guide covers what security headers are, which ones your site should have, and the fastest way to find out where yours stand.
What are security headers?#
Every time a browser requests a webpage, the server responds with the page content and a set of HTTP headers. These headers are short key-value pairs that travel alongside the HTML, invisible to users, carrying instructions intended for the browser rather than the reader.
Security headers are the subset of those instructions specifically designed to reduce the attack surface of your site. They tell the browser things like: do not load this page inside another website's frame, only accept connections over HTTPS, do not execute scripts that were not explicitly approved, and do not transmit cookies over unencrypted connections.
Without these declarations, browsers fall back to permissive defaults that were set decades ago to maximize compatibility. Those defaults made sense when the web was simpler. Today they leave real attack paths open.
Security headers do not require changes to your application code. They are added to your server configuration, your CDN settings, or your hosting platform's response headers. For most sites, adding the core set is a configuration change that takes less than an hour.
Why security headers matter#
The attacks that security headers prevent are among the most common techniques used against real websites. They do not require the attacker to find a vulnerability in your code. They take advantage of browser behaviors that exist by default.
- Cross-site scripting (XSS): An attacker injects malicious scripts into your page. The browser runs them because there is no policy saying it should not, giving the attacker access to session cookies, form data, and anything visible on the page.
- Clickjacking: Your page is loaded invisibly inside another site's iframe. Visitors interact with your page without knowing it, clicking buttons or submitting forms on your behalf.
- Protocol downgrade: A visitor on an HTTPS connection is silently redirected to an unencrypted HTTP version, exposing their session token and any data they submit.
- MIME sniffing: A browser guesses that an uploaded file is executable and runs it as a script, even though the server served it as a plain document.
- Cross-origin data leakage: Scripts from external origins read data from your page through browser-level timing or memory side-channel attacks, a category of vulnerability that became prominent after Spectre.
Worth knowing
Security headers do not require changes to your application code. They are declarations added to your server configuration or CDN settings. A focused configuration session can close multiple attack vectors at once, often without touching a single line of application logic.
The headers your site should have#
Not all security headers carry equal weight. The ones below are organized from most to least critical. Every site should have the first two. The rest are important but depend on your use case.
Content-Security-PolicyCriticalA policy that tells the browser which scripts, stylesheets, images, and other resources are permitted to load on your page. Everything not explicitly allowed is blocked.
Without it, browsers will execute any script present on the page, including those injected by an attacker through a comment field, a third-party widget, or a compromised dependency.
Content Security Policy deep-dive →Strict-Transport-SecurityHighInstructs the browser to only ever connect to your site over HTTPS, even if the user types a plain HTTP address. Once the browser sees this header, it enforces the rule itself without waiting for a redirect.
Without it, a visitor who types your URL without the "https" prefix, or clicks an old HTTP link, is briefly exposed to a connection that an attacker on the same network could intercept or modify.
What is HSTS and Why It Matters →Cross-Origin-Opener-PolicyHighIsolates your browsing context from other origins. Pages you open and pages that open you cannot access each other through the window object.
Without it, a popup or tab your page opened can retain a reference to your window and interact with it through JavaScript, a vector for cross-origin attacks and data extraction.
Cross-Origin Isolation guide →Cross-Origin-Embedder-PolicyHighRequires all resources loaded by your page to explicitly opt in to being loaded cross-origin. Combined with COOP, it enables powerful browser APIs that are otherwise disabled for safety reasons.
Without it, your page cannot enable cross-origin isolation, which means high-resolution timers and shared memory features are unavailable, and Spectre-class timing attacks remain a concern.
Cross-Origin Isolation guide →X-Frame-OptionsMediumControls whether your page can be embedded in an iframe on another site. Setting it to DENY or SAMEORIGIN prevents other sites from framing your content.
Without it, an attacker can load your page invisibly inside their own site, overlaying their interface to trick users into clicking your buttons without realising it.
X-Frame-Options guide →X-Content-Type-OptionsMediumTells the browser to trust the content type declared by the server and not try to guess what a file really is by examining its contents.
Without it, browsers may interpret a text file or image as executable JavaScript if the file contents look like a script, turning an innocuous upload into a code execution path.
X-Content-Type-Options guide →Referrer-PolicyRecommendedControls how much information about the current page URL is shared with other sites when a visitor follows a link or a resource is loaded.
Without it, the browser sends the full URL of every page your visitor came from to every external resource on your site, including analytics scripts, fonts, and advertising tags, potentially leaking session identifiers or sensitive path names.
Referrer-Policy guide →Permissions-PolicyRecommendedLimits which browser features and APIs, such as the camera, microphone, geolocation, and payment request, your page and any embedded iframes are allowed to use.
Without it, any third-party script or iframe on your page can request access to sensitive device features. Most users grant these permissions without reading them carefully.
Permissions-Policy guide →Cookie security attributes also belong in any honest review of a website's security posture. While they are set via the Set-Cookie header rather than a dedicated security header, misconfigured cookies are one of the most common findings in a scan. See the cookie security guide for details.
The fastest way to check your site#
Rather than examining each header by hand, you can check your entire site at once. SiteSecurityScore scans your website in a single request and checks every security header described above, along with TLS configuration, cookie attributes, DNS security records, and the presence of a security.txt file.
To run a scan, go to the homepage, enter your URL, and click Scan. Results are ready within a few seconds and require no account or technical setup.
The scan covers:
- Which security headers are present and which are missing
- Whether present headers are configured correctly or contain known weaknesses
- TLS certificate validity, expiry date, and protocol version
- Cookie security attributes on any cookies set by the server
- DNS security records including SPF, DMARC, and DNSSEC
Understanding your results#
A scan result shows each header's status: present and correctly configured, present but with a known issue, or missing entirely. Findings are grouped by category and ranked by severity so you know where to focus first.
A missing header is not always the most urgent finding. A header that is present but poorly configured can be worse than no header at all. A Content-Security-Policy that allows unsafe-inline for scripts, for example, provides almost no XSS protection despite appearing to be in place. The scan flags these cases explicitly.
Headers can be present and still ineffective
Adding a header to your server is not the same as configuring it correctly. A Content-Security-Policy that permits all inline scripts, or an HSTS header with a max-age of zero, satisfies the presence check but offers no real protection. Always read the value, not just the name.
For each finding, the scan result links to a detailed guide covering what the header does, what the specific issue means, and how to fix it in Apache, Nginx, and Node.js. Use the per-header guides as your reference when making changes:
Keeping headers in place over time#
Security headers are not a one-time fix. Deployments, CMS updates, CDN configuration changes, and platform migrations can silently remove or override headers that were previously in place. A site that passed a security check in January may be missing headers by March, not because anyone made a deliberate change, but because something else did.
Running a scan before and after any significant infrastructure change is good practice. Scheduled monitoring, where your site is scanned automatically each day and changes are flagged, removes the dependency on remembering to check. Daily automated monitoring for Pro and Business accounts scans across all six security categories and sends an email digest when anything changes. See the guide on why continuous monitoring matters for more context on what regressions monitoring catches.
For most sites, the highest-leverage action is the same: run one scan today, fix the critical and high-severity findings, and set up monitoring so you know immediately if something regresses.
FAQ#
Do security headers affect website performance?
No. Security headers are small text values attached to HTTP responses. They add negligible overhead and have no measurable impact on page load times. Some headers like Content-Security-Policy require a little time to configure correctly, but once in place they do not slow down your site.
Can adding security headers break my website?
A misconfigured Content-Security-Policy can block legitimate scripts, styles, or images from loading. Other headers such as X-Frame-Options, X-Content-Type-Options, and Strict-Transport-Security are safe to add in almost all cases without side effects. The safest approach is to use a scanner to understand your current state, then add headers one at a time and test after each change.
Do security headers replace other security measures?
No. Security headers are one layer in a broader security approach. They reduce the impact of certain attacks and close browser-level vulnerabilities, but they do not replace input validation, authentication controls, dependency management, or regular penetration testing. Think of them as the browser-side half of your defenses.
My site uses a CDN. Where should I set security headers?
Most CDNs allow you to configure response headers at the edge, which is the preferred approach because headers are applied to every response regardless of origin. Check your CDN's documentation for "response headers" or "custom headers" settings. If your CDN does not support this, set them at the origin server and confirm the CDN is passing them through by running a scan.
References
Related articles
Check your security headers now
Find out which headers your site has, which are missing, and how to fix them. Free, no account required.