{{ summaryTitle }} {{ summaryValue }} {{ summaryLine }} {{ badge.label }}{{ badge.value }}
Use a neutral public target such as https://example.com/. Missing protocol defaults to HTTPS.

{{ runStatus }}

Choose the profile that matches the checked route rather than the organization as a whole.
The replay command and live probe use the same method.
Default uses the checker identity; browser and crawler profiles use stable representative strings.
Keep the string under 240 characters and do not include credentials.
Applies only when HEAD is selected.
{{ params.fallback_get_on_405 ? 'On' : 'Off' }}
Turn off to inspect only the first response.
{{ params.follow_redirects ? 'On' : 'Off' }}
Use 0–12 hops; 0 is equivalent to first response only.
Use 2–40 seconds.
seconds
Default sends no override.
Turn off when you need only current policy controls.
{{ params.include_deprecated ? 'On' : 'Off' }}
Header values are sent to the target but never added to the share URL. Do not enter credentials.

No extra request headers.

StatusControlObservedNext stepCopy
{{ findingLabel(row.status) }}{{ row.control }}{{ row.observed }}{{ row.recommendation }}
{{ row.priority }}

{{ row.control }}

{{ row.why }}

{{ row.recommendation }}

No immediate remediation queued

Keep the same baseline on redirect, error, authenticated, API, and cache-variant responses.

HopMethodStatusTimePolicy signalRouteCopy
{{ row.hop }}{{ row.method }}{{ row.status }}{{ row.time_ms }} ms{{ row.signal }}{{ row.route }}
HeaderClassValueCopy
{{ row.header }}{{ row.classification }}{{ row.value }}
{{ replayRecipe }}
CORS Policy Risk Checker Review CORS response headers for unsafe origin trust and credential use, then catch cache or private-network combinations that need priority fixes.
HTTP Security Headers Checker Audit pasted HTTP security headers for browser policy, session protection and exposure risks with local scoring and a prioritized fix order.
Gzip Compression Checker Check a public URL or pasted headers for gzip, Brotli, or identity compression with cache-variation checks and measured byte savings.
Hypertext Transfer Protocol (HTTP) Redirect Checker Trace a public HTTP redirect chain hop by hop to identify loops and HTTPS downgrades, compare timing and generate a replayable cURL command.

An HTTP response is more than its body. The status code and response headers tell browsers, caches, crawlers, and API clients how to handle transport, content, storage, cookies, cross-origin access, and redirects before the content is used.

Many header problems are route-specific and invisible on the rendered page. A homepage can look normal while its login response permits caching, an error page omits a script policy, a redirect leaks server details, or an API varies its CORS decision without telling shared caches to vary by Origin. The response users receive at the public edge matters more than an origin configuration viewed in isolation.

Evidence Useful question Common misread
Status and redirect chain Which response actually ended the request, and where did policy change? Treating only the final 200 response as representative of earlier hops.
Security and isolation fields Which browser restrictions are present, absent, broad, or obsolete? Counting presence as a pass without examining the value.
Cache and variation fields May the response be stored, reused, or revalidated for another request? Assuming one cache policy fits public and personalized routes.
Cookie and CORS fields How is browser state protected and which origins may read the response? Auditing an anonymous route and extending the result to authenticated traffic.

The request itself can change the evidence. HEAD is efficient for metadata but some servers reject it or return a different header set. GET follows the normal body-producing path. User-Agent, accepted content codings, extra request headers, redirects, caches, and edge routing can all select a different response.

A header audit is therefore a controlled observation of one request path, not a site certificate. Repeat it for important success, redirect, error, API, static, and signed-in routes. A high score can prioritize cleanup, but only testing those distinct contexts can show whether policy is consistent.

How to Use This Tool:

Probe the exact public route and client viewpoint whose behavior you need to understand.

  1. Enter a public URL target without credentials, signed parameters, or private host details.
  2. Choose an Analysis profile for a balanced web route, strict hardening review, or API endpoint. The profile changes contextual severity; it does not change the received headers.
  3. Select HEAD for a lighter metadata request or GET when method-specific behavior matters. Leave Fallback GET after 405 enabled when a rejected HEAD request should be retried.
  4. Choose the Client viewpoint and accepted content coding only when reproducing client variation. Extra request headers are sent to the target, so use non-secret diagnostic values.
  5. Run the check and start with Header findings plus the first item in Priority plan. Then inspect the redirect chain and raw header inventory for the evidence behind the recommendation.
  6. Repeat the request against representative redirects, errors, authenticated pages, APIs, and cache variants before applying a site-wide conclusion.

Interpreting Results:

The letter grade summarizes the selected model; it is not a standards certification or vulnerability scan. A single failed control makes the overall state Fail, any warning without a failure makes it Review, and only a result without failures or warnings becomes Pass.

  • Read Observed before the recommendation. Missing, broad, contradictory, or route-specific values explain why a row changed status.
  • Informational rows do not affect the overall score. They still identify contextual checks that may matter on another response profile.
  • The posture chart uses a separate per-area scale from the overall grade; do not compare the two as if they were the same formula.
  • Verify the final public response in another client when a CDN, bot policy, authentication layer, geolocation rule, or cache can alter the route.

Technical Details:

The live inspection records each followed response, its effective method, status, elapsed time, location, and header fields. The final hop supplies most policy checks, while redirect continuity is assessed across the chain. Repeated Set-Cookie fields remain separate so attributes can be reviewed per cookie.

Rule Core

Rules classify each applicable control as Pass, Warn, Fail, or Info. The profile changes only specific expectations, such as longer HSTS lifetime in strict mode or reduced framing emphasis for an API.

Area Principal decision rules
Transport HTTPS responses need HSTS. Balanced and API profiles use a one-year minimum; strict uses two years. Preload syntax also needs at least one year, includeSubDomains, and preload, followed by a separate domain-wide readiness decision.
Execution CSP is checked for unsafe script allowances, wildcard defaults, framing protection, and nosniff. Missing CSP or framing is less severe for an API but still remains review evidence.
Privacy and isolation Referrer-Policy, Permissions-Policy, COOP and COEP isolation, CORS, and cookie attributes are interpreted from the final route and selected profile.
Caching no-store, private, revalidation, immutable, positive max-age, and validator evidence determine the cache classification. Contradictory no-store plus freshness directives trigger review.
Exposure Common software-disclosure fields and obsolete headers are flagged. Redirect hops are checked for missing HSTS on HTTPS and repeated stack disclosure.
Request completion Timeouts and server errors fail; client errors, an intentionally unfollowed redirect, or a redirect cap trigger review; a terminal response passes this check.

Two edge rules deserve special care. Credentialed wildcard CORS is a failure. An explicit Access-Control-Allow-Origin on a cacheable response is a warning when Vary omits Origin, because shared reuse can mix origin-specific access decisions.

Formula Core

The overall score excludes informational rows. Pass contributes 1, Warn contributes 0.55, and Fail contributes 0. The mean is converted to a percentage and rounded to the nearest integer.

S=round( 100× ∑i=1nwin )

Here, n is the number of non-informational findings and w is 1, 0.55, or 0 for Pass, Warn, or Fail.

GradeScore boundary
A94 or higher
B84 to 93
C72 to 83
D58 to 71
E57 or lower

Area posture is calculated differently: Pass, Info, Warn, and Fail map to 100, 78, 56, and 18, then the matching rows are averaged within Transport, Execution, Privacy, Isolation, Caching, and Exposure. Those area values help locate concentration of risk; they do not feed the letter grade.

Privacy and Accuracy Notes:

The URL, selected request options, custom User-Agent, and extra request headers are sent to a remote checker, and the checker sends the resulting request headers to the target. Do not enter authorization values, cookies, private hostnames, signed URLs, or other secrets. Returned headers and exports can also contain cookie values, redirect targets, and infrastructure details.

  • The probe does not establish TLS certificate validity; confirm certificate trust and hostname matching with a dedicated TLS check.
  • Redirects are bounded from 0 to 12 and the per-hop timeout from 2 to 40 seconds. A timeout or stopped chain leaves incomplete evidence.
  • Header policy is route- and client-specific. Bot defenses, regional edges, authentication, content negotiation, and cached variants can produce different responses.
  • The scoring and priorities are checker-specific review rules, not official HTTP, browser, or security grades.

References: