Mass Assignment and Excessive Data Exposure

Two common API flaws are mirror images of each other around the data boundary. Mass assignment is an input problem: the API blindly binds incoming request fields to internal object properties, letting an attacker set fields they should not control, such as a role or an account balance. Excessive data exposure is an output problem: the API returns whole objects and trusts the client to hide sensitive fields.

Analogy🏏Cricket

🍳 Think of it like cooking: A recipe can look flawless on paper, but a head chef only truly judges the dish by tasting the finished plate, because heat, timing, and the actual oven reveal problems the written method never shows. Just as tasting the cooked result catches what reading the recipe cannot, DAST probes the running application and catches the misconfigurations and runtime behaviour that reading the source cannot. This reveals DAST's stance: it judges the dish as it is actually served, not the recipe as it was merely written.

Both stem from the same root cause, treating the API's data model as if it matched what clients may safely read or write. They do not. The fix for both is an explicit boundary: allowlist exactly which fields may be set on input, and select exactly which fields may be returned on output. This lesson pairs them because the discipline that fixes one fixes the other.

Analogy🏏Cricket

💰 Think of it like finance: A real audit that actually attempts a sample transaction proves beyond doubt whether a control can be bypassed, with little room for a false alarm, but it can only test the accounts and processes the auditors actually reach. Just as a hands-on audit yields high-confidence, low-false-positive results yet is bounded by what it examines, DAST yields high-confidence findings about real exploitability yet is bounded by the surface it can reach. This reveals its trade-off: what it confirms is solid, but it only confirms what it manages to touch.