Deep audit
See your own website the way an attacker would, from the inside
The free scan reads what any visitor can see. The deep audit goes into the layer behind it: the files, keys and settings that quietly leak data or let people in. It runs only on a site you have verified as yours, it never attacks anything, and every finding comes with the exact fix.
Safe by design: we read, we never exploit. Private by design: findings live only in your account, never on a public page.
What the free scan cannot reach
The free scan is passive. It reads what your site shows every visitor: headers, TLS, the versions your pages load, your reputation. That is enough to catch most of what is wrong from the outside, and it needs no permission because it sees only what a browser sees.
The deep audit is the other half. Some of the most serious exposures are not visible from the front page: a key compiled into your JavaScript, a backup sitting next to your homepage, an admin panel open to anyone, a subdomain pointing at a service someone else can claim. None of it shows up in a passive scan, because none of it is meant to be seen. The deep audit looks for exactly these, on a domain you own, and tells you in plain words what it found and how to close it.
What it finds, and why it matters to you
Secrets baked into your front-end code
Tools that get you live fast often commit and deploy the file that holds your keys, or compile the key straight into the bundle. Anyone who opens your page source gets it, and if it is a payment or AI key, it is billed to you. We read the code your site ships and flag the keys that should never have left your server.
Read more about this check →Files that were never meant to be public
Environment files, database backups, private keys, .git folders, exports and AI-tool configs get deployed by accident all the time. One of them is often enough to get in. We check the paths where they end up and confirm each from its contents, not just a status code.
Read more about this check →Source maps that rebuild your code
A source map left in production turns your minified bundle back into readable source, comments and all. We check whether yours is downloadable, without ever downloading the source itself.
Read more about this check →Admin pages and open directories
A sign-in page open to the internet is where every password-guessing bot starts, and a folder that lists its own files hands over a map of what is inside. We check that these are where an attacker looks first.
Read more about this check →WordPress defaults that make an attack cheaper
If you run WordPress, a few settings are on by default and worth turning off: an interface that lets a thousand password attempts fit in one request, a page that hands out your usernames, a file that names your exact version. We check them.
Read more about this check →APIs that tell strangers too much
A CORS rule that lets any website read your logged-in responses, or a GraphQL endpoint that hands its whole schema to anyone who asks. Both are one-line defaults meant for local development that quietly shipped to production. We check for the dangerous combination only, so a normal setup is never flagged.
Read more about this check →Server and network exposure
Open ports that answer from outside, forgotten subdomains that point at a service someone else can take over and host content from, and cloud storage buckets that list their entire contents to the internet. This layer needs a second, separate permission, because it is about the infrastructure behind your domain rather than the page you publish.
Read more about this check →Known vulnerabilities in your exact versions
We match the software and library versions your site actually runs against public advisory data (OSV, NVD, GitHub Advisory), so you see the vulnerabilities that apply to your build, not a generic list.
Read more about this check →
Safe by design
This is the objection worth answering directly, because a scan that actively probes your site sounds like an attack. It is not one, and that is built into how it works rather than promised in a sentence.
- We look, we never exploit. Confirming a weakness by using it would be the attack the finding warns about. So we never claim a subdomain to prove it is claimable, never call the method that turns an endpoint into a relay, never write to a bucket, and never attempt a login with a username we found.
- Almost every request is an ordinary read. The scan asks for pages the way a browser does. There are exactly two requests that are not a plain read, and both are a fixed question an endpoint asks about itself (what methods do you offer, what is your schema), never a query over your data.
- It stays inside your network's boundary. Requests that would reach a private address are refused, whatever a page claims. The one check that leaves your own domain, reading a storage bucket your site links to, runs only under a second permission you grant.
- It is paced on purpose. The scan is deliberately slow and gentle, not a flood.
The short version: a deep audit is the reconnaissance an attacker does before they act, run by the one person allowed to run it, and stopping exactly where the attack would begin.
Private by design
Your deep-audit findings are yours. They are readable only inside your account and in the PDF you download. They never appear on a public report, they are never part of the public score, and they are excluded from search engines and our sitemap. Nobody learns that your site has an exposure because you checked for one.
We find it without copying it
A scanner that quotes your secret back to you has become a second place that secret lives. So it does not.
When we find a key, the report shows its type, where it was, and a mask (a prefix and a length), never the value. A list of usernames becomes a count and one example, so you can confirm it in a browser. Your source code, your bucket's file index and your API schema are read only far enough to establish the finding, then dropped. What reaches your report and our database is the fact and the fix, never the material.
Every finding ships with the fix
Finding the problem is half of it. The deep audit ranks what it finds worst-first, so you close the most dangerous thing before a wall of minor ones, and each finding carries a precise, copy-paste fix tuned to your stack: the exact setting, the exact command, the exact place. When you have made the change, run the audit again and it confirms the fix from the outside, which is the only place a deleted file and a cached one look different.
You do not need to be a security engineer to act on it. That is the point of the fix travelling with the finding.
How it works
- Verify the domain is yours. Upload a small file or add a DNS record, about two minutes. An active scan of a site is only ever run by its owner, and this is how we know you are one.
- We run the audit. Paced and gentle, a few minutes. You can close the page; we email you when it is ready.
- You get the report. A private page in your account and a full PDF, with every finding, its evidence, and its fix.
Pricing
Free while we are in beta. After launch it is a one-time $39 audit, not a subscription, and early adopters keep it free. The free passive scan stays free for everyone, on any site, forever.
FAQ
- Is it safe? Will it attack my site?
- No. It reads your site the way a browser does and stops exactly where an attack would begin: it never exploits a weakness to prove it, never writes anything, and never attempts a login. It is reconnaissance you are allowed to run on your own site.
- Do you need my password or access to my server?
- No. The audit only reads what your site serves and probes what is reachable from the outside. There is no login to your hosting, no agent to install, nothing to give us but proof that the domain is yours.
- Is what it finds private?
- Yes. Deep-audit findings are readable only in your account and your PDF. They are never on a public page, never in the public score, and excluded from search engines.
- Do you store my secrets?
- No. A secret we find is recorded as a type, a place and a mask, never the value. We find it without copying it.
- Why do I have to verify the domain?
- Because an active scan is only appropriate on a site you own. Verification is a file or a DNS record and takes about two minutes. The free passive scan needs no verification, because it only reads what everyone can already see.
- I am not technical. Can I still use it?
- Yes. Every finding comes with the exact, copy-paste fix, ranked so you know what to do first. If someone built the site for you, the report is also what you send them.
- What does it cost?
- Free during beta. A one-time $39 after launch, no subscription, and early adopters keep it free.
Read more about each check
Each of these explains one finding on its own: what it means, what it costs on the Security axis, and how to close it.
- Exposed API keysA key compiled into the bundle every visitor downloads, and what it costs when it is a payment or AI key.
- Exposed secrets and filesEnvironment files, backups, private keys and exports left reachable at the paths where they usually land.
- Exposed source mapsA map left in production that turns a minified bundle back into readable source, comments included.
- Subdomain takeoverA forgotten DNS record pointing at a service nobody owns any more, and who gets to claim it next.
- CORS misconfigurationThe header combination that lets any website read a logged-in visitor's responses from an API.
- GraphQL introspectionAn endpoint that hands its entire schema to anyone who asks, and why that is a map rather than a leak.
- Public storage bucketsCloud storage that lists its whole contents to the internet, including the files nothing links to.
- WordPress securityThe defaults that make an attack cheaper: XML-RPC, public account names, and the file naming the version.