Methodology

The short version

• Every request is a read. There are no writes, no logins, and no exploitation attempts anywhere in the scanner.
• 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 app returns the same result.
• We would rather miss a low-confidence issue than raise a false alarm.

Every request we send

This is the complete list. Each one is an ordinary GET, identifying itself as xlogs/0.1 (+read-only security probe), with a 12 to 15 second timeout. There are no POST, PUT, PATCH or DELETE requests anywhere in the scanner.

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

8 checks. Each one maps to a condition someone can actually exploit.

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.

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 same checks 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 --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.

Confirmed versus potential

Every finding carries one of two labels, because "we saw it happen" and "this could be a problem" deserve different weight and we refuse to blur them.

Confirmed means xlogs directly observed the exposure: a database table returned real rows to a logged-out request, a private file was actually served, a source map validated, or a service key decoded. There is a response behind it, not an inference.

Potential means a missing protection or a risk we did not exploit to prove: an absent security header, a domain with no SPF record, a dangling DNS name that someone could claim. These are worth fixing, but xlogs did not (and will not) carry out the attack to confirm them, so it does not dress them up as confirmed.

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.

Why there is no reviewer noise here

A finding appears only when the evidence can be shown. That is not a quality target we are trying to hit, it is a property of a scanner with no language model in it: every check is a deterministic rule over a response we fetched, so there is no mechanism by which one could produce a plausible-sounding finding about something it did not observe.

Tools that generate findings with a language model carry the opposite property, and independent review of one popular code reviewer found roughly a quarter of its comments were noise or incorrect. The cost of that is not the wasted minutes; it is that people stop reading. 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 database that hands your rows to a stranger 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 on every change and lists the misses by name.

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 the one thing we do 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 proof of exposure, never the contents of your rows. There is no account, and we do not store your scans.

We do keep an anonymous tally, so we can publish the defect index: per scan we increment counters for the month, which builder platform the app appears to use, which check ran, and whether it found something, plus a coarse bucket for how long the scan took. That is the entire list.

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.