Free security scanner

Run a full security scan of a single page: headers, HTTPS, cookies, and what your server headers give away, and see exactly what's missing, no signup.

We read one page, in one state, without signing in. Being clear about the edges is the point: a scanner that implies it sees everything is the one to distrust. See exactly what we can't see →

  • 17 checks each pass, fail, or needs review
  • Under a minute one page, one scan
  • No signup no account, no email

What we check

  • HTTPS

    The scanned URL loads over https://, not http://

    Pass or fail only: served over HTTPS, or not.

    Without HTTPS, anyone on the same network, a coffee shop hotspot, a compromised router, can read or alter every request and response in plain text.

    Learn more about HTTPS →
  • Strict-Transport-Security (HSTS)

    Strict-Transport-Security: max-age=<seconds>

    On HTTPS sites, present with a max-age of at least 15,552,000 seconds (180 days).

    Without it, every first visit is a chance for an attacker on the network to downgrade the connection back to plain HTTP before it reaches your server.

    Learn more about Strict-Transport-Security (HSTS) →
  • HSTS (present but ineffective)

    max-age=0, an unparseable max-age, or a value under 15,552,000 seconds

    Treated as a fail, not a pass: a header that technically exists but does not actually protect for the full six-month floor.

    A short-lived or malformed max-age expires, or never applies, leaving the same downgrade window HSTS exists to close.

    Learn more about HSTS (present but ineffective) →
  • Content-Security-Policy

    Content-Security-Policy: <policy>

    Present with any non-empty policy, and enforced rather than merely report-only.

    A CSP is the header that bounds the damage of every injection bug you have not found yet. Without one, a single XSS hole anywhere on the site is enough to read session cookies, rewrite what the page says, or post whatever a visitor types to an origin you do not control.

    Learn more about Content-Security-Policy →
  • Content-Security-Policy-Report-Only

    Content-Security-Policy-Report-Only: <policy>

    Counted separately from an enforced policy: we note the directive count and that a header rename is the remaining step.

    It logs what would have been blocked but blocks nothing itself, so an injected script still runs.

    Learn more about Content-Security-Policy-Report-Only →
  • X-Content-Type-Options

    An X-Content-Type-Options response header carrying any non-empty value

    Any non-empty value passes; we never compare it to nosniff. The single case that fails is a header sent with nothing after the colon, which we report as missing rather than as wrong. Send nosniff, since it is the only value the header defines and the only one a browser acts on, but know this scan tells you the header carries something, not that it says nosniff.

    Without it, a browser can MIME-sniff a response and run a file meant to be inert as executable script.

    Learn more about X-Content-Type-Options →
  • Clickjacking protection

    An X-Frame-Options header with any non-empty value, or frame-ancestors inside an enforced Content-Security-Policy

    Present via either mechanism, and neither side is read for what it says. X-Frame-Options clears the check on any non-empty value and fails only when it arrives with nothing after the colon, which we then report as missing; the enforced policy clears it if frame-ancestors appears anywhere in the string. We never verify that the value is DENY or SAMEORIGIN.

    Without it, your page can be loaded inside an invisible iframe and used to trick a visitor into clicking something they never saw.

    Learn more about Clickjacking protection →
  • Referrer-Policy

    Referrer-Policy: <value>

    Present with any non-empty value other than unsafe-url.

    Without it, the browser default sends the full referring URL, query string included, to every link a visitor clicks.

    Learn more about Referrer-Policy →
  • Referrer-Policy (unsafe value)

    Referrer-Policy: unsafe-url

    Flagged specifically, even though a presence-only check would otherwise call it a pass.

    unsafe-url leaks the complete URL, query string and all, to every destination the page talks to, even over an insecure downgrade.

    Learn more about Referrer-Policy (unsafe value) →
  • Permissions-Policy

    Permissions-Policy: <directives>

    Present with any non-empty value, regardless of which capabilities it restricts.

    Without it, a compromised third-party script on the page can request the camera, microphone, or location unopposed.

    Learn more about Permissions-Policy →
  • Permissions-Policy (legacy Feature-Policy)

    Feature-Policy: <directives>

    Counted as partial progress: we report the directive count still needing migration.

    Feature-Policy is ignored by every current browser, so whatever it restricted is unrestricted in the browsers your visitors actually use.

    Learn more about Permissions-Policy (legacy Feature-Policy) →
  • Secure cookie attribute

    Set-Cookie: name=value; Secure, checked on every first-party cookie on an HTTPS page

    Every first-party cookie carries the Secure attribute. We list any that do not, by name.

    A cookie without Secure can be sent over a plain HTTP connection if one is ever made, handing a session or auth cookie to anyone intercepting that request.

    Learn more about Secure cookie attribute →
  • Secure attribute (vendor-managed cookies)

    Set-Cookie: name=value; Secure, checked separately for cookies written by known analytics and ad scripts, for example Google Analytics, Google Ads, Microsoft Clarity

    Used only when every cookie missing Secure is a recognised vendor cookie. One of your own cookies in that set and the whole finding reports under security.cookies-secure instead. Always scored minor, never major: these are first-party by domain, but the vendor script writes them, not your own server.

    The gap is the same interception risk as any missing Secure attribute, but the fix lives in the vendor's own configuration, not in your code.

    Learn more about Secure attribute (vendor-managed cookies) →
  • HttpOnly cookie attribute

    Set-Cookie: name=value; HttpOnly, skipped for cookies that must stay script-readable to function, like _ga

    Every first-party cookie eligible for it carries HttpOnly. We name any that do not.

    A cookie without HttpOnly can be read by any script running on the page, so a single XSS bug turns into session theft instead of a contained bug.

    Learn more about HttpOnly cookie attribute →
  • Third-party cookies

    Cookies whose domain does not match the scanned site, grouped by the vendor that sets them

    Never scored as a defect: we name which vendors are writing cookies through your site, since most owners have not counted them.

    Each additional vendor is a script you are trusting with write access to your visitors' browser, not a security hole in your own code.

  • Server version exposure

    A Server or X-Powered-By response header whose value contains at least one digit

    Flagged when either header carries a value with a digit anywhere in it, and that is the entire test: we never parse a version number out of it. So Server: ECS (sjc/4E44), an ordinary CDN edge identifier that gives away no version at all, is flagged, while X-Powered-By: ASP.NET names your framework and passes because it happens to contain no digit. The finding quotes the header value back to you, so you can see which of the two you are looking at.

    A visible server or framework version tells an attacker exactly which known vulnerabilities to try first, instead of making them guess.

    Learn more about Server version exposure →
  • Mixed content

    Any request made over http:// from a page served over https://

    Flagged if one or more insecure requests are found; we list up to five examples.

    A single HTTP request on an HTTPS page can be intercepted and modified in transit, undermining the encryption on the rest of the page.

    Learn more about Mixed content →

What we can't see

  • Headers, cookies, or transport behaviour on pages other than the one you gave us: we read one page, not a crawl of your site.
  • Vulnerabilities in your server software itself. We flag a Server or X-Powered-By header carrying a digit, not whether whatever it names has a known exploit against it.
  • Anything behind a login, a paywall, or a geofence.
  • Whether a Content-Security-Policy is strict enough to stop a real attacker: we report whether one is enforced, not how permissive its directives are.
  • Cookie or header behaviour that changes between requests, a CDN edge, a feature flag, an A/B test: we read the response once.

Ready to see where you stand?

Scan your site and get your Engineering Score with a prioritized roadmap in under a minute, no signup required.

Scan your site