How HatTest works

A scan, step by step

1. You prove the domain is yours

   Every scan starts with sign-in and a domain-ownership check — a meta tag on your homepage or a DNS TXT record. We only ever probe sites whose owners have authorized it, and exploitable details are only ever shown to the verified owner.

2. We read what your site already serves

   We fetch your pages and the JavaScript bundles they load — the same bytes any visitor’s browser receives — and follow the trail to the API or database backend they talk to. Nothing is injected, nothing is run on your side.

3. We classify what we find

   Everything we observe is checked against our detection catalog — 155 finding classes, from leaked privileged keys and publicly-readable backend data to TLS, email authentication, and exposed files. Client-safe values (a public API key that’s meant to ship) are recognized and never flagged.

4. You get the scoreboard free; the fixes on unlock

   The scan, the severity scoreboard, every informational finding, and a full profile of your stack are free. The negative findings — the actual High, Medium and Low issues, each with redacted evidence and a plain-English fix — unlock with a one-time payment, only when a scan has them, and only after ownership is verified.

How we grade — a plain A–F, no black box

Every complete scan gets one headline letter, A through F. It is not a proprietary score or a weighted model you can’t inspect — it is a single, reproducible rule: the grade is the worst severity band present in the scan.

• ANo negative findings in this scan.
• BLow-severity hardening items only.
• CAt least one medium-severity issue.
• DOne high-severity issue.
• FTwo or more high-severity issues.

This is a deliberate “weakest-link” rule: one high-severity hole caps the grade at D or F no matter how much else is clean, because an attacker only needs one way in. Informational findings never lower a grade. Because the letter is a pure function of the findings, your paid report shows exactly which findings set it and what would move it up — resolve the issues in the binding band and the grade rises by rule, not by our opinion. A grade is point-in-time and is never a claim that a site is “secure.”

Passive by default — what that actually means

The standard scan is strictly passive, egress-only recon: we look at what your site already hands to the public and reason about it. That is a hard safety contract, not a marketing word:

• ✓We read pages, bundles, headers, DNS and TLS — all public.
• ✓We query your public API the way any anonymous visitor could — checking whether it hands back data it shouldn’t. A read, never a write, never a login.
• ✕We never run code on your site or inject anything into it.
• ✕We never write, modify or delete data in a standard scan.
• ✕We never log in or use your users’ credentials in a standard scan.

Because it’s outside-in and read-only, a passive scan can’t harm a live site — the same reason it’s honest about its limits. A site fully behind a login or an aggressive bot-wall comes back as a plain “scan incomplete,” never a guessed pass. We never tell you a site is “secure.”

Ownership-first, always

Two accounts can claim the same domain, so proof is tied to your account, not just the domain: each account gets its own verification token and is checked against its own published proof. Your card is authorized when you pay but only charged after ownership is verified — if you can’t verify, the hold is released and you’re never billed. The result: the details an attacker would want go to the site’s real owner and no one else.

The deep tier: authenticated access testing

Passive recon proves what a stranger can read. The deep tier proves the harder thing a stranger can’t see: whether one logged-in user can reach another user’s data — broken object-level authorization, the flaw behind a large share of real breaches. On a domain you own, using two test accounts you create in your own app, we sign in as user A and check whether A can read (or, where enabled, write) user B’s rows on your backend.

When writes are tested they are value-neutral — we write a field back to the value it already holds, proving the door opens without changing your data — pinned to a single record, capped, and re-checking your ownership at the moment of the write. If a test can’t reach a clean conclusion it’s reported as incomplete, never as a pass. It’s the one part of the product that authenticates, and it’s gated behind consent, ownership, and your own test logins.

Evidence — redacted, encrypted, time-boxed

A finding has to prove itself without handing you (or us) a live liability. Evidence is redacted to demonstrate the issue without exposing the working secret, stored encrypted, and the raw evidence is deleted after 30 days, always. A minimized record — severity, title, a redacted teaser — is kept so your history and monitoring survive, until you delete it; you can delete any scan or your whole account at any time.

Mapped to the standard, not our own jargon

Every finding class is tagged to the industry-standard OWASP taxonomy and to its CWE (linked to the MITRE definition in the paid report), so a result slots straight into how your team and your auditors already think about risk. The full list is public: see all 155 checks we run.

Each finding also carries a confidence label alongside its severity. Confirmed means we directly observed it — read the leaked value, fetched the exposed file, queried the unprotected table, saw the missing control. Potential means we detected it by inference — a known-vulnerable library or CMS version, or a dangling record signalling a takeover is possible — a real signal we have not proven exploitable. We label rather than overstate: a confirmed finding needs no further verification before you act on it.

What it is — and what it isn’t

HatTest is fast, automated security recon focused on a few high-impact exposures: a cheap, honest first look you can run in minutes. It complements but does not replace a human-led penetration test — a person will always find things automation won’t. What it will never do is overstate the result: we report what we find, with evidence and a fix, and we never claim a site is “secure.”