Scanner group

Business logic

These flaws have no payload and no signature. The request is well formed and the server does what its code says; the code just does not enforce a rule the business assumed. Each scanner here turns one such rule into a claim (a balance cannot be spent twice, a price comes from the server, a policy compares the owner) and then looks for evidence that contradicts it: a count of responses, a model's reading of code, or a model's verdict on a live reply.

4 scanners1 rule-based DAST3 LLM-poweredup to Critical

How this group works

One rule, four ways to test it. Step through the scanners and watch what each one treats as evidence. Only one of the four decides without a model.

Race conditionsDAST · no model LLM code reviewreads routes · model LLM business logicplans, runs, judges · model Semantic rule verifierreads RLS and rules · model Claim → test → evidence the rule lives in the developer's head A balance never goes below zero. The price comes from the server, not the client. A policy compares the row's owner, not its primary key. Each scanner turns one such rule into a claim and looks for evidence against it. Three of the four call a model. A model's reply is parsed and capped, and what differs is whose evidence settles the claim. See each step. claim: a redeem cannot succeed twice on one balance POST /api/redeem {"amount":50} x10, same instant one shared connection, so the requests overlap 201 201 201 400 400 400 400 400 400 400 FLAG: 2 or more of 200 / 201 / 204 evidence: a count of status codes. No model is involved, so the same run gives the same answer. claim: this route lets the client set what the server should own route source picked by the review triggers amount: price, // from request.json() model reply: CRITICAL, price manipulation FLAG: the model's reading of the code evidence: the model's judgment. Nothing is sent to the app, so the finding is a static claim. claim: model-planned, then tested on the live app plan: regular_user POST /api/checkout {"price":1} scanner sends it: 201 {"total":1,"paid":true} judge model reads the plan and the response FLAG: only if the judge answers confirmed: true evidence: a live response, but the verdict on it is the model's. No code re-reads the body. claim: this policy protects what it appears to protect CREATE POLICY ... USING (auth.uid() = id) model: id is the primary key, owner is user_id no request is sent, no database is queried FLAG: logical flaw, confidence fixed at 0.70 evidence: the model's reading of the rules. The RLS deep scanner is the one that asks the live database.

1Four scanners, one idea. Each turns a rule the business assumed into a claim and looks for evidence against it. What differs is who supplies the evidence.

2Race conditions. Ten identical mutations at once over one connection. If two or more come back 200, 201 or 204, the check-then-act gap is real. A counted result, no model.

3LLM code review. A model reads high-priority route source, selected by the review triggers, and flags code that trusts the client. It sends nothing to the app. This is the one that catches amount: price.

4LLM business logic. A model writes an attack plan from source, the scanner runs it with two real logins, and a second model call judges the responses. Only a confirmed verdict becomes a finding.

5Semantic rule verifier. A model reads RLS migrations and Firebase rules for logic errors the structural analyzers cannot see. Every finding gets a fixed 0.70 confidence. Without an API key it does not run.

Scanners in this group

ABboth read 100

Race conditions

Check-then-act on two lanes, N identical requests over one connection, and the row lock or atomic update that closes the gap.

DASTHighrace-condition-scanner.md
amount: price← client-controlledCRITICAL+ PLAN_PRICES[plan]

LLM review and AI fixes

Several triggers choose which routes and files are worth the tokens, what the model catches that regex cannot, and the three ways a fix is delivered.

LLMVariesllm-code-reviewer.md
plansendjudgeprice:1 → 201

LLM business logic

A model plans attacks from your source, the scanner runs them with two logins, a second call judges the replies. What is sent, what comes back, and what is never checked.

LLMHighCriticalarchitecture.md
USING (auth.uid() = id) = user_id ✓

Semantic rule verifier

A model reads RLS migrations and Firebase rules for logic errors: the wrong column, uneven coverage, broken tenant scoping. Parsed, capped, fixed at 0.70 confidence.

LLMSASTLow to Criticalsemantic-rule-verifier.md

At a glance

ScannerWhat it looks atWhat it reportsSeverityNeeds
Race condition scannerMutations the authenticated crawl saw succeed with a bodyAn endpoint where two or more identical concurrent requests succeedHighURL; credentials; special DAST scanner
LLM code reviewerHigh-priority route source chosen by the review triggersMissing ownership checks, price manipulation, payment races, auth bypass, business rule violationsVariesRepository; an LLM API key (about $5 to $8 per code-only scan, per its doc)
LLM business logic scannerUp to 30 business-logic source files, up to 50 discovered endpoints, then live responsesAttack plans the judge confirmed against the running appHigh to Critical (judge's choice)Repository; URL; two logins; authenticated or full mode; an LLM API key
Semantic rule verifier.sql files with RLS policies; firestore.rules, storage.rules, database.rules.jsonLogical flaws in security rules, as RLS misconfigurationLow to Critical (the model's choice)Repository; an LLM API key

Why this class matters

Why it matters

Business logic bugs are the most impactful and the hardest to detect. There is no regex for "this payment flow has no idempotency". They are specific to what your app does, they often span several steps, and the server behaves exactly as written. A race lets one balance be spent twice, a client-set price buys the enterprise plan for a cent, and a policy on the wrong column looks protective while it is not. All four scanners here work without a payload; the first three need either two requests at once or a reader that understands what the code is for.

Real-world breaches

Starbucks (2015). Researchers showed a race condition in the gift card system that duplicated balances by transferring the same balance to multiple cards at once. Docker runc CVE-2019-5736. A TOCTOU race let a malicious container overwrite the host runc binary and gain root on the host. Facebook (2013). The ability to delete any photo came from the API checking that the photo id existed rather than that the requester owned it.