API Schema Drift Leaves a Parameter Unprotected
A fintech exposes POST /v1/transfers documented with fields amount, currency, to_account, memo. App & API Protector has a positive-security API rule built from this schema: requests with undocumented parameters are denied. A new mobile release adds an optional reference field and ships to 5% of users before the schema is updated in the protector. Those users' transfers are denied with 400/403, and support tickets spike. The API team's quick fix is to switch the API rule from deny to alert so the release can proceed. Two weeks later, a pen test finds that an attacker can pass an undocumented admin_override parameter that the backend still honors, and the protector is not blocking it. The security team wants to know how this happened and how to prevent the class of problem.
1. Explain how the alert-mode change created the pen-test finding, and what the correct short-term response was.
Read the worked answer
Positive security depends on the schema being both complete and enforced. Switching to alert mode fixed the false positives by removing enforcement entirely - so every undocumented parameter, including malicious ones the backend still processes, now passes. The admin_override finding is a direct consequence: the parameter was never in the schema, alert mode logged it instead of denying it, and the backend honored it.
The correct short-term response to the mobile release was narrower:
- Add
referenceto the schema (or create a scoped exception for that field on that endpoint) so the legitimate new field is allowed while the rule stays in deny for everything else. - If the schema update couldn't ship fast enough, deny-by-default could have been relaxed only for the specific new field, not globally.
Alert mode is a diagnostic state, not a deployment accommodation. Using it to unblock a release converts a precise control into an observability tool and silently widens the attack surface.
2. What process and technical controls prevent schema drift from turning into an enforcement gap?
Read the worked answer
Process:
- Treat the API schema as a versioned artifact owned jointly by API and security teams; a client change that adds fields must update the schema in the same release train.
- Require a review gate: any change from deny to alert on a positive-security rule needs an owner, a reason, and an expiry date, and it should page if it is still in alert past that date.
Technical:
- Keep the rule in deny and manage legitimate additions through schema updates or field-scoped exceptions, never global alert.
- Monitor alert-mode duration as a compliance metric; alert if any positive-security rule sits in alert beyond a short window.
- Reconcile the documented schema against what the backend actually accepts - the
admin_overridefinding shows the backend honored a parameter the schema never knew about. A periodic diff between schema and backend-accepted parameters catches shadow fields. - Run a synthetic test that sends an undocumented parameter and asserts a deny, so a silent switch to alert fails the test.