Documentation
How to use this tool, practical use cases, and technical notes.
The HTTP Security Header Analyzer is designed to return actionable results in under 5 minutes with zero setup. Here is a complete walkthrough of how to use the tool effectively, interpret the output, and act on the findings.
Step 1 — Enter the Target URL
In the "URL to analyze" input field, enter the full URL of the web application or page you want to test. Follow these formatting guidelines for best results:
Input Format | Example | Recommended? |
|---|---|---|
Full HTTPS URL with path |
| ✅ Best — tests the actual authenticated entry path |
HTTPS root domain |
| ✅ Good for baseline homepage check |
HTTP URL (unencrypted) |
| ✅ Valid — will reveal missing HTTPS redirect and HSTS |
Bare domain without scheme |
| ⚠️ May work but use full URL for reliability |
Private IPs / localhost |
| ❌ Blocked — tool only analyzes public URLs |
IP addresses (public) |
| ✅ Supported |
Important: Only analyze URLs for websites you own or have explicit written permission to test. Header analysis involves making an HTTP GET request to the target URL — equivalent to a standard browser visit, but you should ensure you are authorized before testing third-party systems.
Step 2 — Click "Analyze Headers"
The tool makes an HTTP request to the target URL and reads the response headers returned by the server. The request is a standard GET, identical in behavior to a browser loading a page. The tool does not:
Submit forms or interact with page content
Follow authenticated flows or handle cookies
Send multiple requests or perform crawling
Modify or write anything to the target server
Response time depends on the target server's latency, typically completing within 1–3 seconds for well-provisioned servers.
Step 3 — Review the Results Report
The tool returns a structured analysis covering each security header category. For each header, you will see:
Presence status — whether the header is present in the response
Value detected — the actual header value returned by the server
Assessment — pass, fail, warning, or informational
Explanation — what the header does and why it matters
Use the quick-reference scoring guide below to interpret overall results:
Grade | Headers Passing | Interpretation |
|---|---|---|
Excellent | All critical headers present and well-configured | Strong baseline hardening; review CSP directives in detail |
Good | Most critical headers present; 1–2 missing | Minor gaps; addressable with targeted configuration changes |
Fair | Core headers missing (e.g., no CSP, weak HSTS) | Meaningful risk exposure; remediation should be prioritized |
Poor | Multiple critical headers absent | Significant hardening gaps; common in default server configurations |
Critical | No meaningful security headers detected | Likely default/unconfigured server; high-priority remediation needed |
Step 4 — Use the Example Sites for Benchmarking
The tool includes three pre-loaded example targets — Google, GitHub, and Mozilla — that represent best-in-class header configurations. Run an analysis on these before testing your own site to understand what a "good" result looks like:
Example Site | Why It's Useful as a Benchmark |
|---|---|
Google (google.com) | Demonstrates enterprise-scale CSP and Permissions-Policy implementation |
GitHub (github.com) | Strong HSTS, COOP, COEP — excellent model for developer platforms |
Mozilla (mozilla.org) | Security-forward organization; exemplary header hygiene across all categories |
Step 5 — Prioritize Your Findings
Not all missing headers carry equal risk. Use this priority matrix to sequence your remediation work:
Priority | Header | Risk if Missing | Effort to Fix |
|---|---|---|---|
P0 — Critical | Strict-Transport-Security (HSTS) | SSL stripping attacks; HTTPS bypass | 1 line of server config |
P0 — Critical | X-Content-Type-Options | MIME confusion attacks; script injection via content type | 1 line of server config |
P0 — Critical | X-Frame-Options / CSP frame-ancestors | Clickjacking attacks on login/payment pages | 1 line of server config |
P1 — High | Content-Security-Policy | XSS, data injection, malicious resource loading | Hours to days — requires policy design |
P1 — High | Referrer-Policy | Sensitive URL data leakage to third parties | 1 line of server config |
P2 — Medium | Permissions-Policy | Unauthorized camera/mic/geolocation API access | Low-medium — policy string required |
P2 — Medium | COOP / COEP | Cross-origin window attacks; Spectre side-channel | Medium — may break third-party integrations |
P3 — Low | CORP | Cross-origin resource inclusion | Low — single directive |
Step 6 — Retest After Remediation
After making header configuration changes, return to the tool and retest your URL. The tool is stateless — each run fetches fresh headers — so retesting confirms your changes are live and correctly formatted. Common post-remediation issues to watch for:
Issue | Symptom in Retest |
|---|---|
Header set in app but overridden by CDN | Tool shows old value; check CDN header config |
HSTS max-age too short | Present but flagged as weak |
CSP policy too permissive | Present but with |
Header only set on some routes | Passes on homepage; fails on |
Caching serving stale response | Retest shows old headers; add cache-bust query param |
The HTTP Security Header Analyzer is designed to return actionable results in under 5 minutes with zero setup. Here is a complete walkthrough of how to use the tool effectively, interpret the output, and act on the findings.
Step 1 — Enter the Target URL
In the "URL to analyze" input field, enter the full URL of the web application or page you want to test. Follow these formatting guidelines for best results:
Input Format | Example | Recommended? |
|---|---|---|
Full HTTPS URL with path |
| ✅ Best — tests the actual authenticated entry path |
HTTPS root domain |
| ✅ Good for baseline homepage check |
HTTP URL (unencrypted) |
| ✅ Valid — will reveal missing HTTPS redirect and HSTS |
Bare domain without scheme |
| ⚠️ May work but use full URL for reliability |
Private IPs / localhost |
| ❌ Blocked — tool only analyzes public URLs |
IP addresses (public) |
| ✅ Supported |
Important: Only analyze URLs for websites you own or have explicit written permission to test. Header analysis involves making an HTTP GET request to the target URL — equivalent to a standard browser visit, but you should ensure you are authorized before testing third-party systems.
Step 2 — Click "Analyze Headers"
The tool makes an HTTP request to the target URL and reads the response headers returned by the server. The request is a standard GET, identical in behavior to a browser loading a page. The tool does not:
Submit forms or interact with page content
Follow authenticated flows or handle cookies
Send multiple requests or perform crawling
Modify or write anything to the target server
Response time depends on the target server's latency, typically completing within 1–3 seconds for well-provisioned servers.
Step 3 — Review the Results Report
The tool returns a structured analysis covering each security header category. For each header, you will see:
Presence status — whether the header is present in the response
Value detected — the actual header value returned by the server
Assessment — pass, fail, warning, or informational
Explanation — what the header does and why it matters
Use the quick-reference scoring guide below to interpret overall results:
Grade | Headers Passing | Interpretation |
|---|---|---|
Excellent | All critical headers present and well-configured | Strong baseline hardening; review CSP directives in detail |
Good | Most critical headers present; 1–2 missing | Minor gaps; addressable with targeted configuration changes |
Fair | Core headers missing (e.g., no CSP, weak HSTS) | Meaningful risk exposure; remediation should be prioritized |
Poor | Multiple critical headers absent | Significant hardening gaps; common in default server configurations |
Critical | No meaningful security headers detected | Likely default/unconfigured server; high-priority remediation needed |
Step 4 — Use the Example Sites for Benchmarking
The tool includes three pre-loaded example targets — Google, GitHub, and Mozilla — that represent best-in-class header configurations. Run an analysis on these before testing your own site to understand what a "good" result looks like:
Example Site | Why It's Useful as a Benchmark |
|---|---|
Google (google.com) | Demonstrates enterprise-scale CSP and Permissions-Policy implementation |
GitHub (github.com) | Strong HSTS, COOP, COEP — excellent model for developer platforms |
Mozilla (mozilla.org) | Security-forward organization; exemplary header hygiene across all categories |
Step 5 — Prioritize Your Findings
Not all missing headers carry equal risk. Use this priority matrix to sequence your remediation work:
Priority | Header | Risk if Missing | Effort to Fix |
|---|---|---|---|
P0 — Critical | Strict-Transport-Security (HSTS) | SSL stripping attacks; HTTPS bypass | 1 line of server config |
P0 — Critical | X-Content-Type-Options | MIME confusion attacks; script injection via content type | 1 line of server config |
P0 — Critical | X-Frame-Options / CSP frame-ancestors | Clickjacking attacks on login/payment pages | 1 line of server config |
P1 — High | Content-Security-Policy | XSS, data injection, malicious resource loading | Hours to days — requires policy design |
P1 — High | Referrer-Policy | Sensitive URL data leakage to third parties | 1 line of server config |
P2 — Medium | Permissions-Policy | Unauthorized camera/mic/geolocation API access | Low-medium — policy string required |
P2 — Medium | COOP / COEP | Cross-origin window attacks; Spectre side-channel | Medium — may break third-party integrations |
P3 — Low | CORP | Cross-origin resource inclusion | Low — single directive |
Step 6 — Retest After Remediation
After making header configuration changes, return to the tool and retest your URL. The tool is stateless — each run fetches fresh headers — so retesting confirms your changes are live and correctly formatted. Common post-remediation issues to watch for:
Issue | Symptom in Retest |
|---|---|
Header set in app but overridden by CDN | Tool shows old value; check CDN header config |
HSTS max-age too short | Present but flagged as weak |
CSP policy too permissive | Present but with |
Header only set on some routes | Passes on homepage; fails on |
Caching serving stale response | Retest shows old headers; add cache-bust query param |