Security headers check: what your server response tells the browser to do
See what your server tells the browser to do: CSP, HSTS, CORS and the other security headers, each one evaluated by the value it sends. Results on screen and a full PDF.
What a security header instructs, and how the scan reads the policy
Every HTTP response carries a set of headers before the content. Some of them describe the content: type, size, caching rules. Others tell the browser what it may do with the page: which origins it can load scripts and other resources from, whether the page can be shown inside an iframe, whether future visits must use HTTPS and how much of the address to send to other sites as a referrer.
These instructions are enforced by the user’s browser, not by the server. That is why they limit the impact of application flaws: a script injected into a page with a strict Content-Security-Policy is not loaded, even if the injection exists. The header does not fix the flaw. It keeps the flaw from turning into code execution.
How the scan reads it. It requests the home page over HTTP and HTTPS, records every redirect up to the final response and reads the headers of that response and of the intermediate ones. For each policy it evaluates the directives. A Content-Security-Policy with unsafe-inline in script-src is recorded as present but ineffective. A Strict-Transport-Security header that only shows up in the last response of the chain is recorded as late, because the first request already happened without protection. For CORS, it sends requests with different Origin values and observes what comes back in Access-Control-Allow-Origin.
The analysis uses the same engine as cidguard. Each finding comes with severity, the value read from the response and remediation steps. The terms in the result are explained in the glossary.
Each header, and what is evaluated in it
default-src, script-src, object-src, base-uri and frame-ancestors. Wildcards and the unsafe-inline and unsafe-eval keywords in script-src are recorded as a weakened policy.max-age (at least one year), includeSubDomains and which response in the redirect chain carries the header.nosniff, which keeps the browser from reinterpreting the content type declared by the server.Access-Control-Allow-Origin and Access-Control-Allow-Credentials returned to requests from test origins.From the first request to the report
- 01
Enter the domain
Just the domain. No account, no credit card and nothing to install.
- 02
The scan follows the chain
It requests the home page over HTTP and HTTPS, follows each redirect and reads the headers of every response.
- 03
The score shows up
A score from 0 to 100, calculated with the product formula, with the most severe findings shown.
- 04
The report arrives by email
Full PDF with the value read in each header and remediation steps, sent to an email address at the scanned domain.
The header only shows up in the last response. The first visit to the root domain happens without protection, and is recorded as late HSTS.
Why only an email at the scanned domain. The report describes weaknesses of a specific domain. Sending it to any address would let third parties obtain this assessment without any relationship to the domain. If you do not have an email at the domain, contact us and we will send the report once your relationship with it is confirmed.
What the scan does on the target
Request the home page
One request over HTTP and one over HTTPS to the home page, like a browser makes, to read the headers returned.
Follow the redirect chain
Each hop between http and https and between hosts is recorded, with the headers of every intermediate response.
Send requests with a test origin
A few requests with different Origin header values, to observe what the server returns in Access-Control-Allow-Origin.
Evaluate the policy, not the presence
Each header is read by its value: directives, lifetime, subdomain coverage and position in the chain.
Probe ports and services
Port scanning reaches infrastructure that may belong to the provider, as with PaaS and CDNs. This kind of test requires formal authorization from the owner of the environment.
Enumerate paths
There is no attempt to discover routes such as /admin or /.env through wordlists. That procedure generates request volume on the target and only runs with authorization.
Look for application flaws
XSS, exposed panels, keys in JavaScript files and source maps require requests beyond the home page. These areas are part of the full platform analysis, with authorization.
Cover the full inventory
The result covers the domain you enter. Subdomains, staging environments and auxiliary services are part of the full platform analysis.
Frequently asked questions
What are HTTP security headers?
They are response headers that tell the browser what the page may do: which origins it can load scripts and other resources from (Content-Security-Policy), whether it must use HTTPS on future visits (Strict-Transport-Security), whether it can be shown in an iframe (X-Frame-Options and frame-ancestors), whether it may reinterpret the content type (X-Content-Type-Options), how much of the URL to send as a referrer (Referrer-Policy) and which browser APIs it may use (Permissions-Policy). They are set on the server or CDN and enforced in the user’s browser.
Which header has the biggest effect?
Strict-Transport-Security and Content-Security-Policy. The first makes the browser use HTTPS before any request on later visits, which removes the window in which the first HTTP request can be intercepted. The second limits where scripts can be loaded and run from, which keeps a content injection from turning into code execution in the browser.
I have CSP configured. Why does the scan flag an issue?
The scan evaluates the directives, not the presence of the header. A policy with unsafe-inline in script-src allows inline scripts, the most common XSS vector. A policy with default-src * allows any origin. In both cases the header exists, but it does not restrict what it should. The finding names the directive and the value that weakens the policy.
Does the scan detect misconfigured CORS?
Yes. It sends requests with Origin values the server should not accept and reads Access-Control-Allow-Origin and Access-Control-Allow-Credentials in the response. Two patterns are recorded as failures: the server reflecting any origin it receives, and a permissive origin combined with Allow-Credentials set to true, which lets another site make authenticated requests on the user’s behalf.
Does it test the HTTP to HTTPS redirect?
Yes. The scan requests the domain over HTTP and follows each redirect to the final response. It records whether the chain ends on HTTPS, whether the root domain and www behave the same and which response carries Strict-Transport-Security. When the header is only on the final response, the first HTTP request already happened without protection, and the finding is recorded as late HSTS.
Is this the same as an application vulnerability scanner?
No. This scan reads the server response configuration on the home page. Finding XSS, exposed admin panels, keys in JavaScript files or source maps in production requires requests to the application beyond the home page, which only happens with authorization from the owner. These areas are part of the full platform analysis.
Does the score on this page include TLS and email?
No. The full security scan runs TLS, HTTP headers and email on the domain you enter. This page runs only the headers scan, and the score reflects that result. In the full scan, each finding shows which check it came from. It is common for an application with correct headers to sit on a domain without DMARC, which allows email to be sent in the company name.