Website security scan

What the scan checks

The security category is measured against the OWASP Application Security Verification Standard and the OWASP Secure Headers baseline — the same reference points a penetration testing firm uses as its starting position. Concretely:

• API keys, tokens and secrets visible in your client-side JavaScript
• Config files that are publicly retrievable: .env, .git/config, backup files, database dumps
• Missing or weakly configured security headers (HSTS, X-Content-Type-Options, Referrer-Policy)
• Content Security Policy: present, and whether it actually stops anything
• Clickjacking protection via X-Frame-Options or frame-ancestors
• Mixed content: insecure resources loaded over http:// on an https page
• CORS settings that allow any origin at all
• security.txt, validated against RFC 9116

Why a leaked API key is so common

Frontend frameworks make it easy to bake in an environment variable. Too easy. A key exported with a public prefix ends up literally inside the JavaScript every visitor downloads. For an analytics key that is fine — that is what it is for. For a mail API, a payment provider or a database token it is an open door.

The nasty part is that nothing breaks. The site works, the tests pass, the deploy is green. Nobody notices, until somebody who is looking finds it. The scan fetches your bundled JavaScript and recognises the shape of known key formats, so you see it before somebody else does.

Evidence, not a list of ticks

Every finding arrives with its backing: the captured request, the response header exactly as it came in, or the fragment of your JavaScript where the key sits. Alongside it, the report names the standard or best practice the finding rests on.

Just as important: the report also states which checks could not run. If a page sits behind a login or a check hit a timeout, it is listed as 'not tested' — not as 'passed'. An audit report that quietly drops gaps is worse than no report at all.

Read-only, never write

The scan issues GET requests exclusively. Nothing is submitted, nothing is created, nothing is deleted. No attempt is made to actually exploit a weakness it finds — we establish that the door is open, we do not walk through it.

That makes it safe to run against any public URL, including a site you do not operate yourself. Going deeper, with a crawl across multiple pages or the testing of forms, requires verification of the domain.

Frequently asked questions

Is a security scan the same as a penetration test?

No. A scan checks automatically for known, measurable problems. A penetration tester thinks, combines weaknesses and genuinely tries to get through. The scan is the layer before that: it clears the obvious, so a tester can spend their time on the interesting work.

Will my server notice the scan?

You will see a handful of requests in your logs from our user agent. There is no load that resembles an attack and nothing is fired repeatedly.

Can I scan a site that is not mine?

Yes, for the free scan. It only does what any browser does: request public pages. The deeper variants crawl multiple pages and touch forms, which is why they are gated.