What the Security Headers Auditor checks
The Security Headers Auditor gives you a quick outside view of browser-facing response headers on one public URL. Enter a complete http:// or https:// URL, run the audit, and DigitalDomainKit fetches that target once from the server side. The result shows whether six configured headers are present: Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, and Permissions-Policy.
This tool is intentionally narrow. It is a header-presence heuristic for a single response, not a full security certification, not a penetration test, and not a complete policy-quality validator. A site can score well here while still having vulnerable application code, inconsistent route handling, weak authentication, outdated dependencies, exposed admin areas, or an overly broad CSP value. The score is most useful as a fast checklist: it helps you notice missing headers, confirm whether a recent configuration change reached production, and decide what to review next.
How to use the tool
- Open the Security Headers Auditor and find the URL input field.
- Enter one complete public URL, such as
https://example.com. The field is validated as required and must be a URL. - Choose the audit button and wait while the request runs. The current implementation sends one server-side GET request.
- Review the percentage score first, but treat it as a presence summary rather than a final security grade.
- Read the six result rows to see which headers were found or missing on that exact response.
- Check any WAF/CDN signals as passive infrastructure hints only; they are not proof that firewall rules are active or complete.
- Retest the final production URL after making changes, especially if your original URL redirects elsewhere.
Inputs, outputs, and current limits
The auditor accepts one target at a time. Before the request is sent, DigitalDomainKit normalizes the submitted value through its public-target URL handling and rejects private, local, and reserved network destinations. That means localhost, loopback IPs, private network ranges, and reserved addresses are not audit targets. This protects the service from being used as a server-side scanner for internal infrastructure.
| Area | Current behavior | Important limitation |
|---|---|---|
| Accepted input | One required URL using HTTP or HTTPS. | The tool does not crawl a whole site, accept a list of URLs, or test authenticated pages with your cookies. |
| Target safety | Public-network normalization rejects private, local, and reserved targets before the GET request. | Internal staging hosts and local development URLs should be tested with internal tools instead. |
| Request model | One server-side GET request with a 10-second timeout. | Results can differ from your browser, another geography, a signed-in session, or a CDN edge with different rules. |
| Redirects | Redirect following is disabled. | The headers belong to the submitted URL's immediate response, not to a final redirected destination. |
| Header output | Six result rows report whether the configured headers are present. | Presence does not prove the values are strict, complete, route-consistent, or appropriate for every application flow. |
| Rate limiting | Audits are limited to 20 attempts per minute per IP address. | If you hit the limit, wait before retesting rather than repeatedly submitting the form. |
Headers included in the score
The current score is weighted by header presence. Content-Security-Policy and Strict-Transport-Security are worth 20 points each. X-Frame-Options, X-Content-Type-Options, Referrer-Policy, and Permissions-Policy are worth 15 points each. The maximum is 100 points. Missing headers earn no points. The tool does not certify that a CSP blocks every risky source, that an HSTS duration is ideal for your rollout stage, or that a permissions policy matches your product's feature model.
| Header | Weight | Why teams review it |
|---|---|---|
Content-Security-Policy |
20 | CSP can limit allowed script, style, image, frame, and connection sources when carefully designed and tested. |
Strict-Transport-Security |
20 | HSTS tells supporting browsers to keep using HTTPS for a host after a secure visit. |
X-Frame-Options |
15 | This legacy header can reduce clickjacking exposure by limiting whether a page may be framed. |
X-Content-Type-Options |
15 | The common nosniff value helps prevent browsers from interpreting a response as a different MIME type. |
Referrer-Policy |
15 | This header controls how much referrer information browsers include on navigations and subresource requests. |
Permissions-Policy |
15 | This policy can restrict access to browser features such as geolocation, camera, microphone, and related APIs. |
How to interpret the score
Use the score as a triage signal. A low score usually means the response is missing several common hardening headers and should be reviewed. A midrange score means some protections are in place while others still need an owner. A high score means the checked headers were mostly present on this exact response, but it does not prove the site is secure. The tool does not inspect JavaScript behavior, response bodies, cookies, TLS certificate chains, DNS records, dependency versions, login flows, API authorization, or every route on the host.
Route specificity matters. A home page, login page, checkout page, API endpoint, static asset, and redirected HTTP URL can all return different headers. A reverse proxy or CDN may add a header on one path while the application omits it on another. For production hardening, test the canonical HTTPS URL users actually reach, then test representative high-risk routes separately with your internal review process.
Passive WAF and CDN signals
In addition to the six header checks, the auditor looks for passive WAF/CDN response-header signals. These are simple fingerprints found in returned headers, such as Cloudflare-style, Akamai-style, Sucuri-style, AWS CloudFront/WAF-style, ModSecurity, Imperva/Incapsula, or generic firewall-looking values. This can help explain why a response looks the way it does, especially when a CDN or edge service adds headers before traffic reaches an origin server.
Do not treat these signals as proof of protection. A provider can be present without a web application firewall policy being enabled. A WAF can be active without exposing a recognizable header. Edge routing, custom header rules, multiple CDNs, application gateways, and cached responses can all make passive fingerprints incomplete. If firewall posture matters, confirm rule sets, managed protections, bypass rules, logging, and challenge behavior in the provider dashboard or with an authorized security test.
Example verified behavior
On September 16, 2026, the repaired tool behavior was retested with a local loopback target and a public sample URL. Submitting http://127.0.0.1 was rejected because private, local, and reserved network targets are not allowed. That is the expected safety behavior for a server-side network tool.
The same retest against https://example.com completed and returned six result rows. The score was 0 for that response because none of the six weighted headers were present in the response observed by the tool during that run. This example is useful because it shows the scoring model clearly: the result is based on returned header presence from one GET request, not on a broader assessment of the domain, its hosting provider, or the quality of an absent or present policy.
Practical remediation workflow
- Start with the final public HTTPS URL that users should land on, not only an HTTP URL that redirects.
- Save the current result so you know which of the six headers are missing from the immediate response.
- Decide where headers should be set: application code, framework middleware, web server, reverse proxy, CDN, or hosting control panel.
- Add one policy at a time in staging when the header can affect application behavior, especially CSP and Permissions-Policy.
- For CSP, inventory scripts, styles, images, frames, fonts, workers, analytics, payment widgets, and API connections before tightening directives.
- For HSTS, confirm HTTPS is stable across the host and important subdomains before using long durations or preload-oriented settings.
- Deploy through your normal change process, clear CDN caches if needed, and retest the exact same URL with redirects in mind.
- After the presence check passes, manually review values for appropriateness rather than assuming the score alone is enough.
Troubleshooting common results
| Problem | Likely cause | Recommended action |
|---|---|---|
| The tool says the URL cannot be fetched. | The input may be malformed, unreachable, private, local, reserved, or blocked by public-target validation. | Use a complete public HTTP or HTTPS URL and avoid localhost, loopback, private IP ranges, and internal hostnames. |
| The HTTP URL scores differently from the HTTPS URL. | Redirect following is disabled, so each submitted URL is checked as its own immediate response. | Audit the final HTTPS URL directly when reviewing production browser security headers. |
| A header appears in your browser but not in the tool. | A CDN, geographic edge, authenticated session, service worker, or route-specific rule may be changing the response. | Compare raw response headers from your server logs, CDN logs, browser developer tools, and this external check. |
| A high score still leaves security concerns. | The auditor checks presence of six headers only. | Review actual values, application vulnerabilities, access controls, cookies, TLS, dependencies, and route coverage separately. |
| A WAF signal is missing even though you use a provider. | The provider may hide identifying headers or the tested route may bypass the edge layer. | Confirm provider status in your CDN/WAF dashboard and test the correct hostname and path. |
| You receive a rate-limit message. | The IP address has reached 20 audits in one minute. | Wait for the rate-limit window to pass, then retest only the URLs you need. |
Responsible use and security scope
Use this auditor only for sites you own, administer, or are authorized to assess. The tool sends a server-side GET request from DigitalDomainKit infrastructure to the submitted public URL. It is designed for lightweight configuration review, not for stealth scanning, load testing, vulnerability exploitation, credential testing, bypass attempts, or mapping third-party infrastructure. The private-target rejection and per-IP rate limit are part of keeping the tool focused on legitimate public web checks.
Security headers are one layer of defense. They can reduce browser-side risk when configured well, but they do not replace secure application design, dependency management, TLS hygiene, access control, logging, backups, incident response, or human review. Treat the output as a conversation starter for your engineering or security workflow: it tells you what this one public response exposed, then your team decides which changes are appropriate for the application.
Related DigitalDomainKit tools
Use the Security Headers Auditor with nearby checks when reviewing a public site. The CSP Header Generator can help draft an initial Content Security Policy after you identify that CSP is missing. The HTTP Methods Auditor checks how a public URL responds to methods such as GET, POST, PUT, DELETE, OPTIONS, TRACE, and PATCH. The SSL Checker reviews certificate details for HTTPS targets. The Redirect Checker helps inspect redirect chains separately, which matters because this auditor does not follow redirects. The Safe Browsing Checker provides a separate reputation-style URL lookup and should not be confused with header hardening. The DNS Lookup can help confirm that the hostname resolves publicly before you retest.
Editorial and technical notes
This page is built and maintained by Digital Domain Kit. The verified technical method on September 16, 2026 is: Livewire validates the submitted field with required|url, resets previous state, rate-limits audits to 20 per minute per IP address, normalizes the destination through PublicNetworkTarget::httpUrl(), rejects private/local/reserved targets, and sends one server-side GET request with redirects disabled and a 10-second timeout. The six weighted presence checks are Content-Security-Policy at 20 points, Strict-Transport-Security at 20 points, X-Frame-Options at 15 points, X-Content-Type-Options at 15 points, Referrer-Policy at 15 points, and Permissions-Policy at 15 points.
Last reviewed and retested: September 16, 2026. The retest confirmed that http://127.0.0.1 is rejected and that https://example.com returned six result rows with a score of 0 in the observed run. For background on these browser headers, see MDN documentation for Content Security Policy, Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, and Permissions-Policy. To report a problem with this page or the tool output, use the DigitalDomainKit contact page.