Methodology

The short version

• Every request is a GET or a HEAD, enforced in the code that sends it. There are no form submissions, no logins and no exploitation attempts, and the page crawl skips links that look like actions (log out, delete, unsubscribe).
• No account, no credentials, and no repository access. You paste a URL, that is all we take.
• No score. Every finding carries its own evidence instead of rolling up into one number.
• No AI at scan time. The same responses produce the same findings under the same rule version; a live app can answer differently between scans, so a result describes the moment it ran.
• We would rather miss a low-confidence issue than raise a false alarm.

Every request we send

This is the complete list. Every request to your site is an ordinary GET, identifying itself as xlogs/0.1 (+read-only security probe), with a 12 to 15 second timeout. We never send your site a POST, PUT, PATCH or DELETE. The one POST in the scanner goes to the public OSV advisory database, never to you, and only when your site has already served its lockfile.

Our request budget. One scan sends at most 60 requests to the site, counting every one of them: the page, up to 25 bundles, source maps, the private-file checks, the page crawl and the database reads. At most 8 are in flight toward one site at a time, however many people are scanning it. A scan that reaches the budget stops and says what it did not check; it never reports the rest as clear. A scan runs once, when someone asks for it. There is no background crawler.

We also refuse to scan anything that is not a public web address. Private, loopback, link-local and cloud-metadata addresses are rejected before a request is made, and that check runs again on every redirect hop.

What we check

The 14 kinds of finding a live scan can report, from the 11 checks it runs. Each finding names what it observed and what it did not test.

What else we observe, and do not grade

A scan sees more than it reports as findings. All of the below is read from responses the scan already fetched, none of it carries a severity, and none of it moves a verdict. It is here because a tool that shows you observations without saying which ones are judgements is inviting you to read the wrong ones as alarms.

What we deliberately do not flag

"Severity must be earned" is easy to claim and worthless unless it is falsifiable. So here is the actual list of conditions our checks see and choose not to report, and why. If you think one of these is wrong, that is a specific, checkable disagreement, which is the point.

What we report, but not as loudly as it looks

These are findings the scanner keeps, and grades by a second piece of evidence rather than by the first thing it saw. Each one used to be a critical or a high on something ordinary. The finding stays visible; what changed is the word beside it and the sentence under it, so that what is printed is true of the thing found. Decided 2026-09-06 and 2026-10-16; each one is pinned by a test, and most are permanent cases in the published false-positive corpus.

Standard identifiers, and what they are not

Every finding carries a CWE identifier and its OWASP Top 10 (2021) category, so you can look it up or match it against another tool's output. You can also download any scan as SARIF 2.1.0, the standard format, and open it in VS Code or upload it to GitHub code scanning. That export is free and includes every finding, like everything else here.

Two honest caveats. One finding, subdomain takeover, has no CWE listed, because none of the existing identifiers fit it well and forcing a wrong one would be worse than leaving it blank. And these labels are a convenience, not a compliance product: an xlogs scan is not evidence for SOC 2, ISO 27001, or PCI DSS, and we will never present it as such.

The live-site checks also run from a command line, so you can block a deploy on them: xlogs --url https://myapp.com --fail-on high exits non-zero if anything at or above that severity is found, and also if a security check could not run: a gate that could not test your database has not passed it (--allow-inconclusive accepts such a gap, and still names it). And --sarif out.sarif writes the same report for CI. The gate is read-only like everything else: it blocks a deploy, it never touches your repository, and it needs no token with write access.

The command line tool is released on its own: the release these pages run is v0.2.4 (2026-10-06), and the copy on npm, xlogs-scanner 0.1.0 (2026-08-13), is older still, so either can report differently from a scan on this site.

What was seen, and what it means

Every finding carries two labels, because "we saw it" and "this is a problem" deserve different weight and we refuse to blur them.

Seen: confirmed means xlogs directly observed it: a database table returned real rows to a logged-out request, a private file was actually served, a source map validated, or a key was in the code your site serves. There is a response behind it, not an inference.

Meaning: potential means the impact depends on something xlogs did not test or cannot know: whether a table is meant to be public, whether a served key still works, whether an attack a missing header would block is possible on your app, whether a dangling DNS name can actually be claimed. xlogs does not carry out the attack to find out, so it does not dress the impact up as confirmed. Each finding says what was observed, what was not tested and what to do, which written rule set its grade, which ordinary setups produce the same observation, and what would change the grade.

Meaning: established appears only when the evidence plus a statement you supplied settles it, such as a private-access requirement in the command line tool's policy file. Even then it says only that the read conflicts with your requirement, not what the rows hold or whether anyone read them. Results graded before rules 1.9 carry one label, Confirmed or Potential, and keep it.

Related: when a leaked key is visibly a live key rather than a test key, xlogs raises its severity, because the same kind of secret is not the same risk. A public test key is real exposure but a far smaller fire than a live one.

Every number here traces back to a response

Nothing on a report is estimated, modelled or averaged. Each finding names the request that produced it and what came back, each count is derived from the findings above it rather than stored separately, and the receipt lists the checks that ran so a zero can be read as measured rather than assumed. If we cannot show you where a number came from, we do not print the number.

What we refuse to invent

A security tool has a standing incentive to make results look more dramatic, because a frightening report feels more valuable than a quiet one. These are the four places we refuse it.

• Absence is reported as absence. When a check could not complete, it says so and the result is not clean. No evidence is not negative evidence, and it is not positive evidence either.
• We never guess a vulnerability from a design pattern. Recognising a framework tells us what to check, never what is wrong. A finding needs an observation behind it.
• We never report a version we did not see. Guessing a library version from a filename, then matching it against advisories, produces a long and confident list of things that may not be true.
• We do not exploit anything to make a finding stronger. Where a scan stops is where the evidence stops, and the confidence label says which side of that line a finding sits on.

What deterministic rules do and do not guarantee

Every check is a deterministic rule over a response we fetched, and no language model decides what counts as a finding. That gives reproducibility: the same responses produce the same findings, and a finding always points at the response behind it. It does not give correctness. A rule can match something it should not, and ours have: the false-positive benchmark lists every false positive by case id. No language model means no plausible-sounding finding about something that was never observed; it does not mean no noise.

Tools that generate findings with a language model carry the opposite property. When the Lychee project counted a month of an AI code reviewer's findings on its own pull requests (290 across 28 pull requests, published September 2025), it called 15% useless and 13% based on a wrong assumption, the rest ranging from nitpicks to quality and security improvements, and said the split was specific to its codebase and practices. That is one project's count, not a rate for every such tool. Noise like that costs more than the minutes spent dismissing it: people stop reading, and a scanner is only useful for as long as its output is worth opening.

Why there is no security score

A single number out of 100 has to be tuned to look meaningful, and the tuning is where honesty goes. Once a score exists, there is pressure to make it move: adding checks that are easy to pass, or weighting cosmetic items so the number spreads nicely across users. Several tools in this category include performance and accessibility checks inside a security score.

We report findings instead. Each one states what we observed, where, and what an outsider could do with it. A secret key served to every visitor is critical whether or not the rest of your configuration is tidy, and no average should be able to soften that.

What we publish instead of a score is how often we are wrong: the false-positive benchmark runs two adversarial corpora through the shipped scanner, lists every false positive by case id with the interval its sample size allows, and is checked against the detectors before every deploy.

What xlogs cannot see

A clean xlogs scan means the checks above found nothing, not that your app is secure. Here is what is outside our reach, and who to use instead.

If you need dependency scanning, compliance evidence, or coverage across cloud and infrastructure, you want a full application-security platform, not this. xlogs answers one question well: is your deployed app leaking something right now, and how do you close it.

Muting a finding

You can mark a finding as reviewed, with a reason: not a real issue, risk accepted, or handled another way. That note lives in your own browser and is sent nowhere, because there is no account to attach it to.

A muted finding stays in the report, dimmed, with your reason shown, and it does not change the verdict or the counts. Muting records that you looked at something and decided. It is not a way to make a problem disappear, and we will not build one.

Privacy, and what we keep

We read only what your app already serves publicly. For the database check we record the table name, its column names, and an approximate row count as evidence, never the contents of your rows. There is no account, and a scan is not kept unless you choose to keep it (a share link, Watch, a verified badge); the privacy page lists each one with what it keeps and for how long.

We do keep an anonymous tally, so we can publish the defect index. For each completed scan we increment counters for the month: which builder platform the app appears to use; each check's outcome (found something, found nothing, did not apply, could not finish); a coarse reason when a check could not finish; the technologies observed and how sure each detection was; which rule for the security badge the scan reached; and a coarse bucket for how long it took, plus a running total of completed scans. That is the entire list. Scans of our own test targets (a deliberately vulnerable app we scan after every release, and xlogs.com itself) go to a separate internal tally and into nothing we publish; until October 19, 2026 they were counted with everyone else's.

No URL, no hostname, no IP, no finding detail, no data from your app. There is no identifier of any kind in those counters, so nothing in them can be traced back to you. We publish counts only and will never publish a list of scanned or affected sites. The open-source command line tool sends none of this: counting happens only here. Full statement in the privacy policy.