If you have a security blog, an MSP knowledge base, or a client report template that links to securityheaders.com, this one is for you. Scott Helme's public-facing tool, which has graded HTTP security headers for the better part of a decade, is in the middle of a wind-down. Snyk (the current owner of the public API) announced on Scott's blog in April 2026 that the public API would be shut down. The browser-facing site has been running on borrowed time since.
We built a free security-headers checker as part of AttackEdge's public tools. It does the same job in plain English, hosted in Sydney, with no signup and no rate limit on individual checks. If you have a blog post, a client report template, or an internal runbook that links out to securityheaders.com, you can swap the link without changing the substance of the article. The embed snippet at the bottom of this post is the drop-in replacement.
What follows: a quick recap of what the original tool did, what ours does (with a few differences called out so readers know what they are getting), and the embed snippet you can paste into your own page.
What securityheaders.com did, and why people still link to it
The original tool took a URL, sent a single GET request, and graded the response on a list of HTTP security headers: Strict-Transport-Security, Content-Security-Policy, X-Frame-Options (and frame-ancestors as part of CSP), X-Content-Type-Options, Referrer-Policy, and Permissions-Policy. It produced a grade from A+ down to F, with a per-header breakdown. It was the copy-and-paste tool of choice for anyone explaining browser-side hardening to a client or a junior developer.
Two things made it sticky. First, the grade itself was a conversation starter: showing a client an "F" on their own site was a faster way to get budget for a header rollout than any abstract talk about XSS or clickjacking. Second, the page was public and bookmarkable, so MSPs and consultants embedded the link in client-facing reports and dashboards.
With the public API shut down, the embed-in-an-iframe pattern and the badge-image pattern both go dark. The tool itself might keep running for a while in some form (re-homed, scaled down, or community-maintained); the integration paths that depended on the public API will not.
What the AttackEdge tool does
At /tools/security-headers you paste a URL, we send a single GET request from our scanner with a clearly identified user-agent (AttackEdge-SecurityHeadersChecker/1.0), and we grade the response headers from A+ to F. Eight headers are checked. Every header gets a plain-English fix when it is missing or weakly configured, with the specific server directive you need to add. No signup, no rate limit on individual checks, no upselling-before-results pattern.
Three things to know about how we approach it differently:
- Plain English, not header names. The default audience is a small-business owner reading the report alongside their developer. Each header explanation says what the header does for the business, not what RFC defines it.
- Hosted in Sydney. The check runs from AU infrastructure. For AU-hosted clients that is one less round-trip and one less jurisdictional question.
- One GET, no crawling. We read the response headers, stop reading the body after 64 KB, and do not follow internal links. The user-agent is easy to identify in your logs.
A few intentional differences from the original. We do not currently issue a public sharable badge URL with a fixed grade graphic. We do not have a public API for headless integrations. Both are on the list; neither is in the free tool today. For a single-page reader-facing replacement, those gaps usually do not matter. For an automation use-case, talk to us at hello@attackedge.io.
What changes for your blog or knowledge base
Three audiences typically link out to a public headers checker: bloggers writing "how to secure your WordPress site" guides, MSPs documenting their hardening playbook in a client knowledge base, and software vendors linking to a public verifier from their own help docs. The replacement work is small but worth doing once, properly, rather than letting the link rot.
For bloggers and content writers
Search-and-replace any reference to https://securityheaders.com with the AttackEdge tool URL, https://attackedge.io/tools/security-headers. The link text usually does not need to change. If your post embeds the original grading iframe, replace it with the snippet below. If you cite specific grade letters ("most WordPress sites get a D") those calls usually still hold against our grading; we tuned it to be roughly consistent with the original, within one grade either way.
For MSPs and consultants
The most common pattern is a sentence in the client-facing report that says "you can verify this any time at securityheaders.com by entering your domain". Swap that sentence to AttackEdge and replace the screenshot. The plain-English fix lines under each header are usable directly in client conversations, which means you can drop the "here's what HSTS means" sidebar that most reports re-explain in three different ways.
For software vendors
If your help docs say "to verify your CSP rollout, run your domain through securityheaders.com", change the link target. We do not currently have a public API to wire into a CI pipeline, so if your existing integration depends on a programmatic call, contact us directly rather than swapping URLs.
The embed snippet
Drop this into your post or knowledge-base page. It renders a small call-out card with a domain input that opens the AttackEdge tool with the user's domain prefilled as a query string, the same UX a reader expects from the old embed.
Pure HTML, no framework dependency, no external JS, safe for any CMS that allows raw HTML:
<div style="border:1px solid #ddd;border-radius:8px;padding:16px;margin:24px 0;font-family:system-ui,sans-serif">
<strong>Check your security headers</strong>
<p style="margin:6px 0 12px;font-size:14px;color:#444">Plain-English A+ to F grade, hosted in Sydney. Free, no signup.</p>
<form action="https://attackedge.io/tools/security-headers" method="get" style="display:flex;gap:8px;flex-wrap:wrap">
<input name="url" placeholder="https://example.com.au" required style="flex:1;min-width:220px;padding:8px;border:1px solid #ccc;border-radius:6px" />
<button type="submit" style="padding:8px 16px;border:0;border-radius:6px;background:#101010;color:#fff;cursor:pointer">Grade headers</button>
</form>
</div>It posts the URL as a url query parameter to /tools/security-headers. The tool page reads the query string and prefills the input, so the user lands on the tool with their URL already in the form (one click to run). If you want a smaller version, strip the inline styling and let your site CSS handle it. The behaviour does not depend on the styling.
If you want a one-line link instead of an embed: <a href="https://attackedge.io/tools/security-headers"> Grade your security headers </a>. Works everywhere.
What to verify on your own site first
Before you tell your readers their headers are fine, verify your own. The list, in the order we see them most commonly missing on AU small-business sites: HSTS (the largest single gap), CSP (the largest single risk), X-Content-Type-Options, Referrer-Policy, Permissions-Policy. The post on the five HTTP headers that fix most of your browser-side problems runs through each one with examples.
If you are looking at this as part of a wider security review (not just the embed swap), the free check covers headers alongside DNS, email authentication, and TLS posture in one pass.
We will keep the tool free and public. The embed snippet above is the supported way to integrate it from a blog or knowledge base until we have an API. If you need anything we have not built yet, say so and we will look at it.