Security Testing: SAST, DAST and Fuzzing APIs

A team runs a static analysis tool on every pull request, sees a clean scan, and ships an API with a BOLA vulnerability that lets any authenticated user read any other user's data by changing an ID in the URL. The static scanner was never going to catch this — it reads source code, and the code that fetches an order by ID looks completely ordinary; nothing in the code's structure signals that the authorization check for that ID is missing, because the absence of a check that should exist isn't a pattern a scanner reading syntax can recognize. This is not a failure of the tool; it's a mismatch between what the tool was built to find and what the team assumed it covered.

Different testing techniques catch structurally different categories of flaw, and none of them, individually or even all together, is a substitute for the others. Understanding what each one actually sees — and, just as importantly, what each one is structurally blind to — is what lets a team build a testing strategy that has real coverage instead of a checklist of tool names that sounds thorough but leaves the exact gap an incident eventually finds.

Analogy🏏Cricket

🏏 Think of it like cricket: Preparing a team for an overseas tour uses several genuinely different kinds of practice, and none of them substitutes for another. Video analysis of an opponent's bowlers, studied in a meeting room, reveals patterns in a bowler's action and field settings that are real and useful — but it cannot tell you how a specific batter's technique actually holds up against genuine pace and swing on a live pitch, because that's a different kind of information, only available from an actual net session. A net session against throwdowns at a fixed, predictable pace reveals timing and shot selection — but it cannot expose how a player handles the unpredictable variation of a real match situation, a genuinely hostile crowd, or a bowler who changes their plan mid-spell. Just as video analysis, net practice, and match-simulation each reveal a different category of weakness that the others structurally cannot, static code analysis, dynamic testing against a running API, and fuzzing each reveal a different category of vulnerability the others structurally cannot. Just as no serious team preparing for a tour would rely on only one of those training methods and call preparation complete, no serious security testing programme relies on only one of these techniques and calls the API tested. The insight is that thorough testing isn't more of one technique — it's the right combination of structurally different techniques, each covering what the others cannot see.