Before you run it
Is it safe to run against my site?
Last updated 14 August 2026
It is the first question every technical visitor asks, and it deserves more than a sentence. Here is every safeguard, and where each one is enforced.
You prove the site is yours before anything is fetched
We give you a file name and a path on your own web root, and a value to put inside it. Nothing is sent at your site until that file comes back with the right value in it. We check it again at the moment the scan starts, so a proof that was true last week has to still be true now.
A DNS TXT record on its own is refused. Anyone who can add a TXT record can point a name at a machine they do not run, and we want proof of control over the web root we are about to test.
If the proof fails, we tell you which of the named reasons it was and what to do about it, with a short how-to for WordPress, cPanel, Netlify, Vercel, Nginx, Apache and Shopify.
We scan the server you proved, and only that one
We pin the IP address your proof came from. Every request in the scan goes to that address, with your host name in the Host header. A DNS change part way through the scan cannot move us onto somebody else's machine.
The pinned address is re-checked as a public address before we use it, and every redirect hop is re-checked the same way. A redirect that would take us off your site is refused instead of followed, because chasing it would scan an unverified third party.
Read-only by design, and proven by test
The scanner never sends PUT, DELETE or PATCH at your site, and it never submits one of your POST forms, because those change your data. Five probes send something other than a plain read:
- A login attempt with two factory passwords, on a login page we found.
- A GraphQL schema query, if a GraphQL endpoint answers.
- One prompt-injection probe, if a chat endpoint answers.
- TRACE at your root.
- OPTIONS at your root.
A test in our suite asserts that every other probe issues a read, and that the login attempt writes no attacker state. It fails our build if that stops being true.
Checks our attacker model invents are held tighter still. Those may use GET, HEAD or OPTIONS and nothing else, and a proposal that carries a request body is refused before it can run. A proposal we cannot make provably safe is stored and marked unusable, and it never executes.
Every scan is capped, and we say what we did
| Limit | Value |
|---|---|
| Page fetches to a scan | 25 |
| Bytes to a request | 2 MB |
| Seconds to a request | 8 |
| Redirects followed | 3 |
| Frontier model calls to a scan | 6 |
| Scans an hour across the whole service | 80 |
Requests go out one at a time. That is a lighter load than one person browsing your site.
The scanner names itself in every request it sends, as FrontierCyberDefence-Scanner/0.1, with a link back to us. If you are reading your access logs and wondering who we are, that line is the answer.
Everything that ran is recorded as it runs, and the whole log is in your report. What we did to your site is on the record.
What the full scan adds
The free scan is deliberately scoped: one host, read-only, gentle on your site. The paid full scan keeps every safeguard above and widens the surface it maps.
- It discovers and maps the subdomains that resolve under the domain you proved you own.
- It reads your DNS records and grades your email authentication: SPF, DKIM and DMARC.
- It reads your certificate and TLS, and your software versions and their support dates.
- It looks at your network and cloud edge, the services and storage an attacker sees from outside.
- Give it a test credential and it tests behind your login, across the access controls between accounts.