About HeaderScan.dev

Made by Koen Schipper

HeaderScan.dev is made by Koen Schipper, an independent Laravel developer. It is part of the same collection as HeaderScan, RedirectPath, CheckSSL and SiteAudit: focused tools for understanding a public website’s technical behavior.

The aim is to connect an observed result with a useful next step. Findings include evidence, explanations and links to practical guides so you can decide whether a change fits your website.

About Koen Schipper and his work ↗ (opens in a new tab)

How a scan works

1. Validate the URL and its public DNS addresses, then send a GET request.
2. Follow supported HTTP redirects within the scan limits and inspect the final response.
3. Evaluate applicable header rules and create a report with redacted header details and practical findings.

Explore a fixed example using the same report layout

What is checked

• Checks HTTPS, HSTS, selected Content-Security-Policy directives, framing protection, MIME sniffing protection and referrer policy.
• Examines Set-Cookie attributes in the final response, including Secure, HttpOnly, SameSite, Domain, Path and lifetime information.
• Reviews Cache-Control, validators, selected Vary behavior and cache or proxy hints.
• Reports selected server disclosures and cross-origin configuration. Some findings are informational and do not affect the score.

Limits of the result

• Uses a 15-second scan budget and follows at most five redirects. Header and response-body size limits can also stop a scan; the body limit is 64 KiB across requests.
• Analyzes the final response only. Headers or cookies received on an earlier redirect are not included in the header assessment.
• Sends GET requests without browser cookies, does not retain response cookies for later requests and does not execute JavaScript.
• Checks declared headers, not their complete behavior in a browser. It does not test application vulnerabilities, fully validate a CSP or perform a complete CORS assessment.
• A result describes one response from the scanner’s connection. Authentication, location, caching and other requests can produce different headers.

A result describes one measurement from this scanner. It is not a security certification, a complete website audit or a promise of search visibility. “Unknown” means the check could not establish a result; it is different from a confirmed failure.

Understanding scores

Only applicable, weighted findings with a pass, warning or fail status count. A pass earns the full weight, a warning half and a failure none; the counted weights are normalized to 100.

Informational and unknown findings are excluded. An incomplete redirect chain has no header score. Review the evidence and applicability of each finding: a high score is not a security guarantee.

Read the finding and its evidence before changing a setting. Verify the deployed change with a new scan and a relevant independent check; a higher score alone does not establish that a website meets its requirements.

Report data & sharing

No account is required. Scan reports are public: anyone who knows the result URL can open them. The URL is based on the hostname and tool and shows the latest available scan for that host. A later scan, including a different path on the same host, can change the displayed report.

Reports expire after seven days and are eligible for daily cleanup. Live report pages ask search engines not to index them; this is not access control. The fixed example reports are separate public pages with fictional data and do not expire.

Stored reports contain selected findings and redacted evidence, not the full HTML, robots.txt or sitemap bodies. Query values in submitted and captured HTTP URLs and sensitive or unrecognized response-header values are masked. Hostnames, URL paths, query parameter names, connected IPs, selected metadata and public certificate details may remain visible. Do not submit confidential URLs or treat redaction as a guarantee that every secret will be recognized.

The scan runs from the server against the public target. It does not receive your browser’s signed-in session. Requests can appear in the target server’s logs.

Guides & corrections

The guides use AI-assisted research and drafting, with practical examples, verification steps and links to primary documentation. Scanner-specific explanations describe the implemented checks and their limits. Example values and configuration snippets need to be adapted to your own application.

If a result or explanation seems wrong, include the tool, the relevant finding and the expected behavior when reporting it. Remove credentials and confidential information from any example you send. A report URL can change or expire, so include the relevant observation as well.

Contact Koen Schipper about a correction ↗ (opens in a new tab)

How the tools are funded

Reports and guides may include a clearly labeled Cloudways affiliate link. If you follow that link and become a paying customer, we may earn a commission that helps support these tools.

Using the scanners and guides does not require a hosting purchase. Affiliate placements do not change the checks, scores or technical advice. Compare a provider’s features with your requirements; choosing a host does not by itself resolve a finding.