LogoTools

Need help securing your website?

We help businesses with:

  • Web Development
  • Ecommerce Integrations
  • Automation
  • Technical SEO
Talk To Us

Fetches a URL's raw HTTP response headers and grades them against well-known security-header best practices - the same headers tools like securityheaders.com check: Strict-Transport-Security, Content-Security-Policy, clickjacking protection, Referrer-Policy, Permissions-Policy, and whether the response leaks its software stack via Server/X-Powered-By.

Why this needs a server

A browser's fetch() can't read most response headers from a different origin - that's a deliberate CORS restriction, not a missing feature. Checking another site's headers requires a request that isn't subject to same-origin restrictions, which is what WebSync's own server does here: it fetches the URL and hands back the raw headers for grading in your browser.

What the grade does and doesn't mean

The score is a fixed checklist with hardcoded point deductions, not a penetration test or a guarantee of security - a site can score 100 here and still have vulnerabilities these headers don't address, and a lower score doesn't mean a site is actively unsafe, just that it's missing some standard defense-in-depth headers.

Headers set by client-side JavaScript (rather than the server's own response) won't show up, since this is a plain HTTP fetch that doesn't execute anything on the page.

Frequently asked questions

Is the URL I check sent anywhere?

Yes, to WebSync's own server, which fetches it (GET request, headers only - no page content is downloaded or stored) to read its response headers, since browsers can't read another origin's headers directly. Nothing else on this site works this way.

Why does it use GET instead of a lighter HEAD request?

A meaningful number of servers respond to HEAD requests differently than GET (or reject HEAD outright), which would silently produce wrong results. This uses GET but aborts the transfer the moment the response body starts arriving - headers are always sent first, so nothing beyond them is actually downloaded.

A header I know is set isn't showing up - why?

Two common causes: it's being set by client-side JavaScript rather than the server's actual HTTP response (this only sees the real response headers), or it's set differently depending on the request path/resource type and the URL checked doesn't happen to set it.