How does Sloptic find slop?

It only looks from the outside

Sloptic never sees your code. It checks the app the way a visitor would over the web. This method works on any app you give it, which is what makes two unrelated apps comparable at all.

What counts as slop?

It has to be wrong in every app. Before a behavior is considered slop, it must answer a simple question: Is there a legitimate app for which this behavior is correct? For example, a table any visitor can read can be right for a product catalogue. Allowing duplicates may be correct for logs but wrong for payment transactions. These examples are cases where an app can legitimately exhibit a particular behavior and thus wouldn't be considered slop.

However, behaviors like exposed secrets, SQL injection, an unhandled server error, or a pathologically slow app, are wrong for any app you come across. No app on earth exists where such behaviors are "correct" and thus these are considered slop and Sloptic docks them.

It has to be proven. An instance of slop rests on something only that instance could produce, with evidence to back it up. Unlike traditional DAST tools, where a false positive can be dismissed with only some wasted time, the slop Sloptic sees must be trustworthy on their own, since (1) the score is meant to be taken at face value, and (2) any human intervention affects the objective nature of Sloptic.

How Sloptic scores

• deduction onlyNothing is earned for passing, but you get penalized for failing. This mirrors how failures work: successes are quiet but failures are visible. A lower score is better.
• risk pricedSloptic penalizes slop based on expected harm, or how often it hurts someone multiplied by how bad it is (i.e. the classical risk formula).
• dampedOne kind of slop counts once. If, for example, there are 20 instances of missing headers, Sloptic will not charge 20 times, but only once. This prevents a single kind of slop from dominating the score.
• unboundedSecurity, quality and performance each report their own subtotal and the three sum to the score. There are no limits on how high the score can be.

Where the scores come from

A penalty is not a matter of taste. Every number traces to a published authority, and where a finding lands inside that authority's range is set by what the check saw. You can find the full rationale in the open grader.

Different failures answer to different authorities, and only severity sets the number.

• security holesCVSS, the industry scale for how bad a vulnerability is, reconciled against the Bugcrowd rating taxonomy.
• quality failuresISO/IEC 25010, the software quality standard, crossed with Nielsen's severity scale for how much a fault hurts a user.
• performanceGoogle Lighthouse, charging only the distance an app falls below Lighthouse's own line for good.
• accessibilityaxe-core, priced by the impact rating it assigns each barrier against WCAG.

Two kinds of checks for slop

Passive checks read what your app already shows every visitor. Running them on a stranger's site is no different from visiting it.

Active checks go looking for holes by sending real attacks (because some instance of slop are security vulnerabilities). Doing that to a site you don't own is considered unauthorized testing, so they only run when ownership is proven. Learn more about domain verification here.

How we validate our checks

Checks are calibrated against apps with known answers because no single target proves much by itself.

• a matched pairOne reference app intentionally broken, one clean. A check that can't tell these apart does not get added.
• apps broken on purposeDVWA, Juice Shop, VAmPI and bWAPP, the intentionally vulnerable apps the industry already uses with documented faults.
• an outside benchmark GapBench, a recall benchmark with an answer key for testing security scanners.
• a populationMore than 1,600 real deployed apps, which shows how often a fault occurs but not whether one actually exists or not.