How an audit works
From the moment you enter a domain to the report you read, here is exactly what we do and don't do.
1 The crawl
We start at the address you enter. If you type a bare domain we try HTTPS first and fall back to plain HTTP only if the site has no HTTPS at all, in which case that becomes a finding.
From there the crawler follows links that stay on the same site, breadth first, up to the page limit you choose (15 by default, 50 at most). It fetches three pages at a time with a short pause between batches. It skips links whose paths suggest they change something, such as logout, delete, remove, unsubscribe or cancel, and it ignores images, PDFs and other downloads.
It also downloads up to 15 of your site's own JavaScript files so they can be checked for outdated libraries and leaked keys.
2 The checks
First we identify component names and versions from resource URLs, script banners, inline scripts and generator metadata. We query current OSV advisories for identifiable npm versions and supported Drupal core versions, then retrieve publication dates, CVE aliases, source links and published fix versions. Matching advisories appear first in the report, newest published first; older issues remain visible when they still match.
Advisory lookups are made during each scan, rather than being limited to a fixed list of recent incidents. Missing versions, lookup failures and incomplete advisory responses remain coverage gaps. WordPress core and plugin detections are shown for manual verification because comprehensive live advisory coverage is not available in this scanner. A plugin asset's version query parameter is not treated as proof of its installed version.
Everything collected is run through a set of passive checks. A few of them make extra requests: a single request to see what your 404 page reveals, an OPTIONS request to see which HTTP methods are advertised, one request with a foreign Origin header to test your CORS policy, and plain GET requests for a short list of files that should never be public, like /.git/HEAD and /.env.
A file only counts as exposed if its contents match what that file really looks like, so sites that answer every URL with a 200 page don't produce false alarms. The full list of checks covers each one.
3 The review
When AI review is available, Claude receives a summary of the crawl, detected technologies, the retrieved advisory evidence and every automated finding. It does four things:
- gives each finding a verdict: confirmed, likely, needs a manual check, or false positive;
- adjusts severity to your site's context, so a missing header matters more on a page with a login form than on a static brochure;
- explains each issue in plain language and writes a specific fix;
- points out risks the rules didn't catch, clearly labelled as unverified.
Page content is treated strictly as data. If a page contains text that tries to instruct the AI, it's ignored and may be reported as an observation.
The model explains retrieved evidence; it does not invent new vulnerabilities or use its memory as a current advisory feed. If AI review fails or is unavailable, the report says so and keeps the automated matches and fixes visible.
4 The grade
Each audit starts at 100 points. Every open issue subtracts points based on its severity, using Claude's adjusted severity when there is one. Findings Claude dismissed as false positives, and its unverified observations, don't count.
| Severity | Points off | Typical example |
|---|---|---|
| Critical | 30 | Public .env or .git folder, expired certificate |
| High | 15 | CORS that lets any site read logged-in data, secrets in JavaScript |
| Medium | 6 | Missing Content-Security-Policy, outdated jQuery |
| Low | 2 | Server version in headers, missing Referrer-Policy |
| Informational | 0 | No security.txt file |
| Grade | Score |
|---|---|
| A | 90–100 |
| B | 75–89 |
| C | 60–74, or any high-severity issue |
| D | 40–59, or any critical issue |
| F | below 40 |
What an audit can't tell you
Passive checks see what any visitor sees. They can't find SQL injection, cross-site scripting that needs a crafted input, broken access control, problems behind a login, or flaws in your business logic. A good grade means the common, visible mistakes aren't there. It is a strong first pass, not a substitute for a penetration test.