What a Scanner Cannot Find

Every chapter so far has described something a machine can check. This one is about the part that is left over, and it is a larger part than a clean report suggests.

The shape of the blind spot

A scanner reasons about one request at a time. It can tell whether a response carried a field it should not have, whether an endpoint refused a caller it should have refused, and whether a header is missing.

What it cannot do is know what your service is for. A refund endpoint that lets any authenticated user refund any order they are allowed to view is a serious flaw, and to a scanner it looks like an endpoint working correctly. Every request is authenticated, every response matches the contract and nothing in the exchange is malformed.

what one request can prove, and what it cannota response carrying a field it should notan endpoint that answered the wrong callera header, a TLS version, an old hostone calla refund anyone may issue on any ordera flow driven out of the order it assumeswhat you do with a partner's answerbelow, each request is valid

Three categories that live below the line

Business logic abuse. A sequence of legitimate calls produces an outcome nobody intended. A discount is applied twice because two endpoints each check it independently, or a workflow runs out of order because the state machine is implied rather than enforced. Another version changes a value between the step that prices it and the step that charges it.

Automated access to flows that assume a human. This is API6:2023 Unrestricted Access to Sensitive Business Flows, and OWASP's own examples are commercial rather than technical. Buying out limited stock to resell it, reserving most of the seats on a flight and cancelling them to move the price, and farming a referral programme for credit. Each individual request in those examples is legitimate, and the volume and intent are the problem. OWASP's recommended defences are correspondingly non-technical, including device fingerprinting, human detection and pattern analysis of behaviour.

The APIs you consume. API10:2023 Unsafe Consumption of APIs is about trusting a response from a third party more than you trust one from a user. Its references name CWE-20 for improper input validation, CWE-200 for information exposure and CWE-319 for cleartext transmission. A scanner probing your API from outside never observes that exchange at all. OWASP's guidance is to validate and sanitise data from integrated APIs as you would any other input. It also asks you to keep those calls on a secure channel and to hold an allow list of destinations rather than following redirects.

What covers the rest

Threat modelling on the flows that carry money or identity. Walk one flow end to end and ask what an actor who wants the wrong outcome would try. Checkout, refunds, invitations, password reset, plan changes and anything with a quota or a credit. A morning per flow finds things no tool will.

Code review aimed at the checks rather than the logic. For the categories in this guide, the useful review question is not whether the handler is correct. It is whether the ownership check is present, whether the writable fields are an allow list, and whether the response is a projection rather than a serialised model.

Penetration testing, once the cheap half is done. A tester whose first two days go to missing headers and unbounded pagination is a tester spending your money on what a scanner does for free. Run the mechanical checks continuously so the human time starts where the machine stopped.

Monitoring for the shapes that only appear in aggregate. Volume anomalies on a sensitive flow, one identity touching an implausible number of objects, and error-rate patterns that look like enumeration. These are the traces business logic abuse leaves, and they are visible in production rather than in a scan.

In Routebase

The product documentation says which category has no scanner rather than implying full coverage.

API10:2023 Unsafe Consumption of APIs is listed as not covered, because it would require analysing the upstream and third-party APIs your service calls, and those are outside the scanner's view of your own surface. Nothing in the product claims otherwise.

The coverage of API6:2023 is deliberately partial and says so. api6-business-flow identifies state-changing endpoints whose path or tags mark them as a sensitive flow, matching tokens such as checkout, purchase, payment, transfer, signup, invite, redeem and coupon. It then sends a single OPTIONS request per matched endpoint rather than triggering the flow, and it checks the response headers for rate-limit signalling. A missing signal raises a Medium finding at low confidence, which is a prompt to look at a flow rather than a claim that it is abusable.

That is an honest design for an unautomatable category, and it is worth reading the way it is meant. The scanner is telling you which flows deserve the threat-modelling morning, not that it has tested them. See the Not covered section of the Scanner Reference.