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 — 156 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 — and the report names the specific checks that couldn’t complete, so “incomplete” is an answer you can act on rather than a shrug. Every report also states what this method cannot cover. 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 user B’s rows on your backend.

The deep tier is read-only today. A cross-user write test exists and is built to be value-neutral — writing a field back to the value it already holds, pinned to a single record, capped, and re-checking your ownership at the moment of the write — but it is currently disabled, so no scan modifies your data. If we ever enable it, it stays behind your explicit per-scan consent. If a test can’t reach a clean conclusion it’s reported as incomplete, never as a pass. This is 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 156 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.

Where our vulnerability data comes from

Version-based findings — a vulnerable WordPress plugin, an outdated JavaScript library — are matched against public vulnerability feeds that we mirror on a schedule rather than query live, so a scan never depends on a third party being up. That also means a very recently published advisory may not have reached our mirror yet; we would rather be a little behind than fail a scan or guess.

• WordPress plugin and theme vulnerability data from Wordfence Intelligence. www.wordfence.com
• JavaScript package vulnerability data from OSV.dev, which aggregates the GitHub Advisory Database and the OSV malicious-packages database. osv.dev
• Known-exploited-vulnerability flags from the CISA Known Exploited Vulnerabilities catalog (US government, public domain). www.cisa.gov
• CVE identifiers and records are © the MITRE Corporation. www.cve.org

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.”