DEV Community

Guardr
Guardr

Posted on • Originally published at guardr.io

SecurityHeaders.com API Is Gone — Here's the Migration

#security #webdev #api #devops

If you have CI/CD pipelines or scheduled audits built on api.securityheaders.com, now is the time to migrate — the API has been discontinued and no new or renewed subscriptions are being issued. Better to move before your key stops working than after.

The SecurityHeaders.com API has been discontinued — no new subscriptions, no renewals. The free web UI at securityheaders.com is still live, but if your existing key expires you have nowhere to go. This post is a practical migration guide with real before/after curl examples and a working GitHub Actions workflow.

Why developers used it in the first place

HTTP security headers — things like Content-Security-Policy, Strict-Transport-Security, X-Frame-Options and Permissions-Policy — are one of the easiest ways to harden a website against a whole class of attacks: XSS, clickjacking, protocol downgrade, MIME sniffing and more. Browsers respect them natively, no client-side code required.

The problem is that getting them right is tedious. Each header has its own syntax, edge cases and gotchas. Miss one, misconfigure another, and your security posture quietly regresses with no visible symptoms.

SecurityHeaders.com solved this with a simple letter grade. Paste a URL, get an A–F score and a list of what's missing or misconfigured. The API took that same scan and made it programmable — so developers could:

  • Gate CI/CD pipelines — fail the build if headers regress before a deploy goes live
  • Run scheduled audits across dozens of domains and feed results into a dashboard or Slack alert
  • Generate compliance evidence for SOC 2, PCI or internal security reviews
  • Power client reports for agencies managing security across multiple sites

If any of those sound useful, read on — this guide covers how to replicate them with the Guardr API.

Quick recap: what happened

  • January 2023 — SecurityHeaders.com launched a paid API
  • June 2023 — Probely acquired SecurityHeaders.com from its creator Scott Helme
  • June 2025 — Snyk acquired Probely
  • April 2025 — Probely announced the API would be retired in April 2026, giving a full year's notice
  • April 2026 — API discontinued, no new or renewed subscriptions

Credit to Scott Helme and the Probely/Snyk team for the generous notice window. The web scanner at securityheaders.com is a genuine contribution to web security and it continues to exist. This is just about replacing the programmatic endpoint.

The migration in one swap

The most common use case was a single GET per domain returning a grade. Here's the before/after:

Before (SecurityHeaders.com):

curl -H "x-api-key: YOUR_OLD_KEY" \
  "https://api.securityheaders.com/?q=example.com&hide=on&followRedirects=on"
Enter fullscreen mode Exit fullscreen mode

After (Guardr API):

curl -H "X-API-Key: YOUR_NEW_KEY" \
  "https://api.guardr.io/v1/scan/example.com"
Enter fullscreen mode Exit fullscreen mode

Same auth header style, same GET-per-domain pattern. The hide and followRedirects params don't have equivalents — results are private to your account by default and redirects are always followed.

Want to try it without signing up? The GET endpoint works keyless at 20 req/day per IP, returning grade + score only:

curl https://api.guardr.io/v1/scan/example.com
Enter fullscreen mode Exit fullscreen mode

What the response looks like

Here's a real response from a domain with issues (trimmed but every field name is exact):

{
  "domain": "example.com",
  "scanned_at": "2026-04-18T12:46:48.373Z",
  "grade": "C-",
  "score": 58,
  "categories": {
    "tls": 55,
    "headers": 0,
    "cookies": 100,
    "dns": 90,
    "exposure": 100
  },
  "issues": [
    {
      "title": "HSTS not enabled",
      "severity": "high",
      "category": "TLS",
      "description": "Strict-Transport-Security header is missing...",
      "remediation": {
        "effort": "moderate",
        "warning": "Before enabling HSTS, make sure your entire site works over HTTPS — including all subdomains if using includeSubDomains.",
        "snippets": [
          {
            "platform": "Cloudflare (_headers)",
            "code": "/*\n  Strict-Transport-Security: max-age=31536000; includeSubDomains; preload"
          },
          {
            "platform": "Nginx",
            "code": "add_header Strict-Transport-Security \"max-age=31536000; includeSubDomains; preload\" always;"
          }
        ]
      }
    }
  ],
  "total_issues": 8,
  "issues_truncated": false
}
Enter fullscreen mode Exit fullscreen mode

A few things worth calling out for developers:

remediation.effort tags every issue as quick-fix, moderate, or requires-planning. Useful for sprint planning — you can filter for quick wins before tackling CSP rollouts.

remediation.warning surfaces the gotchas inline. HSTS warns you about subdomain rollout. CSP warns about third-party integrations breaking. These are the notes that usually live in a senior engineer's head.

remediation.snippets is an array of platform-specific config code — Cloudflare _headers format, Nginx add_header, Apache Header always set. No translating from generic advice.

Field mapping from the old API

What you want SecurityHeaders.com Guardr
Letter grade summary.grade grade
Numeric score not available score (0–100)
Timestamp summary.timestamp scanned_at (ISO 8601)
Header findings summary.headers (traffic-light) issues[] with severity + remediation
Raw response headers rawHeaders[] not returned (use HEAD request if needed)
Grade cap explanation summary.gradeCap categories object

The key conceptual shift: the old API was header-centric (organized around raw HTTP headers). Guardr is issue-centric (organized around "what's wrong and how to fix it"). Better for CI/CD gating; less useful if you specifically wanted a raw header dump.

GitHub Actions workflow

Here's a migrated version of the most common CI pattern — nightly scan with grade-based fail:

# .github/workflows/security-scan.yml
name: Security Header Scan

on:
  schedule:
    - cron: '0 4 * * *'
  workflow_dispatch:

jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - name: Scan site with Guardr
        env:
          GUARDR_API_KEY: ${{ secrets.GUARDR_API_KEY }}
        run: |
          response=$(curl -sf \
            -H "X-API-Key: $GUARDR_API_KEY" \
            "https://api.guardr.io/v1/scan/example.com")

          grade=$(echo "$response" | jq -r '.grade')
          score=$(echo "$response" | jq -r '.score')
          headers_score=$(echo "$response" | jq -r '.categories.headers')

          echo "Grade: $grade | Score: $score | Headers: $headers_score"

          if [[ "$grade" == "D" || "$grade" == "E" || "$grade" == "F" \
                || "$grade" == "C" || "$grade" == "C-" ]]; then
            echo "::error::Security grade regressed to $grade"
            echo "$response" | jq '.issues[] | select(.severity == "critical" or .severity == "high")'
            exit 1
          fi

          if (( headers_score < 70 )); then
            echo "::error::Headers score dropped to $headers_score"
            exit 1
          fi
Enter fullscreen mode Exit fullscreen mode

Add GUARDR_API_KEY to your repo secrets and generate the key in the Guardr dashboard under Settings → API Access.

What about forcing a fresh scan?

The GET endpoint returns a cached result (up to an hour old). For CI runs where you want a live scan, use the POST endpoint:

curl -X POST "https://api.guardr.io/v1/scan" \
  -H "X-API-Key: YOUR_NEW_KEY" \
  -H "Content-Type: application/json" \
  -d '{"domain":"example.com"}'
Enter fullscreen mode Exit fullscreen mode

POST scans complete in 5–15 seconds. Note the per-domain scan quota — on Free that's once every 7 days, on Solo once every 24 hours. For large sweeps, trigger one POST per domain then use GET for all subsequent reads.

Rate limits

Plan Burst limit Scan window
Public (no key) 20 req/day per IP read only
Free 5 req/min 1 scan/domain/7 days
Solo ($7/mo) 15 req/min 1 scan/domain/24 hrs
Starter 30 req/min 1 scan/domain/24 hrs
Pro 60 req/min 1 scan/domain/6 hrs
Agency 120 req/min 1 scan/domain/1 hr

Every response includes X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset and Retry-After on 429s. Respect Retry-After — don't hammer on rate limit errors.

What Guardr covers that the old API didn't

Beyond security headers, a Guardr scan also checks:

  • TLS — HSTS presence and config (hstsMaxAge, hstsIncludesSubs, hstsPreload as structured fields), HTTP→HTTPS redirect
  • DNS — DNSSEC and CAA records
  • Cookies — Secure, HttpOnly and SameSite attributes
  • Exposure paths — /.git/HEAD, /.env, /phpinfo.php, /wp-login.php
  • JS bundle secret scanning — leaked OpenAI, Stripe, AWS, Supabase keys in shipped JavaScript

What Guardr's v1 doesn't have (yet)

  • rawHeaders[] dump — use a HEAD request if you need raw headers
  • History endpoint, compare endpoint and PDF-via-API — these exist in the dashboard but aren't exposed as API endpoints yet

Other alternatives (honest take)

  • Mozilla Observatory — free, excellent for manual one-off checks, no public API
  • Qualys SSL Labs — gold standard for deep TLS analysis, doesn't cover headers
  • Roll your own — 30 lines of Python + cron if you only need HSTS presence

Guardr is the closest drop-in for the grade-based API + remediation use case. For deep TLS work, SSL Labs is still the right tool. For manual spot checks, Mozilla Observatory is free and great.

I'm Anatoli, building Guardr solo. The API launched this month specifically to give SecurityHeaders.com users somewhere to land. If there's an endpoint or feature from the old API that doesn't have a Guardr equivalent and it's blocking your migration, drop me a message — I want to hear about it.

Full docs and response samples: guardr.io/docs/api

Top comments (0)