How the grade works
What Sloptic looks at, what it counts as a finding, how those become a number, and what it does not claim. The grader is open, so anything here can be checked against the code.
It only looks from the outside
Sloptic never sees your code. It checks the app the way a visitor would, over the web, with no source and no description of what the app is meant to do. That constraint is the point: the same method works on any app, whatever it was built with, which is what makes two unrelated apps comparable at all.
What counts as a finding
It has to be wrong in every app. Before a check is added it must survive one question: is there a legitimate app for which this behavior is actually correct? A table any visitor can read is exactly right for a product catalogue, so the check cannot fire on an open table. It fires on what is in the columns. Whether this user should see that record is intent, and stays human. Whether a stranger can read a table containing contact_email is not.
It has to be proven, not guessed. A finding rests on something only that fault could produce, and echoing back our own payload never counts. The file-access check does not match the path it asked for, it matches a line out of the password file it should never have received. The scripting check requires the payload to actually execute in the page, not merely appear in it. One filter check keys on a fragment of the app's own query template surfacing in an error, which nothing we sent could have produced.
How the score is built
- deduction onlyNothing is earned for passing. This mirrors how failure actually works: defending seven of eight injectable inputs is still a breach, so the seven add nothing and the eighth adds its full penalty.
- risk pricedA penalty is expected harm, how often it hurts someone multiplied by how badly, rather than raw severity. Nothing else outranks a single catastrophic security fault.
- dampedOne root cause counts once. Variants of the same flaw collapse to a single finding, and repeats within a category decay sharply, so ten pages missing one header are not ten findings.
- per area, not out of 100Security, quality and performance each report their own subtotal and the three sum to the score. Scaling to 100 was tried and reverted: a denominator makes apps with different amounts of surface incomparable, which defeats the purpose.
Two kinds of checks
Look-only checks read what your app already shows every visitor: its settings, the page it serves, how fast it loads, whether a screen reader can use it. Running them on a stranger's site is no different from visiting it, so they run on any URL.
Hands-on checks go looking for holes by sending real attack traffic. Doing that to a site you do not own is unauthorized testing, so they run only once ownership is proven. What that involves.
What happens when a check cannot run
Every check returns one of three answers, and the third is the one that matters. It found the fault, it tested and did not find it, or it could not establish the conditions to test at all. A check with no login in front of it cannot report that the login is safe.
That third answer is never quietly folded into a pass, because a clean result that was never actually tested is a missed fault wearing a pass. Each one records why it could not run. The same rule applies when a target is too noisy to read: an app that answers every request with error grammar carries no signal, so the benign case is checked first and the result is marked untestable rather than guessed. Every grade ships the tally, and on the population we measured, the median app had 62% of the battery apply to it.
How the checks are validated
Checks are calibrated against apps with known answers, in layers, because no single target proves much on its own.
- a matched pairOne reference app deliberately broken, one deliberately clean. A check that cannot tell them apart does not ship.
- known-broken appsDVWA, Juice Shop, VAmPI and bWAPP: the deliberately vulnerable apps the industry already uses, whose faults are documented by people with no stake here.
- a third-party benchmarkGapBench, an outside recall benchmark with its own ground truth, run politely and without any attempt to defeat its protections.
- a populationAround fifteen hundred real deployed apps, which shows how often a fault occurs but never whether a given call was right, because a corpus has no answer key.
What it does not claim
It never says you are safe. A 0 means nothing was found, not that nothing is there. The score cannot tell a defended thing from an absent one, and calling that clean would be a false assurance.
It sees the logged-out surface. Faults behind a login it cannot get past are missed, and the coverage report says so rather than implying it saw everything.
Some findings belong to the platform, not the app. An app on a hosting subdomain may be serving the platform's own login page, and a fault there is not the team's. That boundary is narrowed, never claimed closed, which is one reason a human stays in the loop.
Precision is vouched in places, not everywhere. The classes with explicit precision rules are checked. The rest is reported as unaudited rather than dressed up as verified, and most of it is presence checks where getting it wrong is structurally hard.
The miss rate is not measured yet. The audit of what Sloptic fails to catch, across the whole catalog, is still running. Until it finishes, no recall figure is claimed.