There is no single control. Security is a property you design in and enforce continuously, and the layers each cover a different failure.
TLS on everything, with no plaintext fallback. Real authentication appropriate to the sensitivity — keys for identification and metering, OAuth or mTLS where it matters. Authorization checked at the object level on every request, not just at the route: the most common serious API vulnerability is an authenticated user reaching another user’s records by changing an ID. Input validation driven from your JSON Schema so the contract and the validation cannot diverge. Rate limiting to blunt abuse and enumeration. Logging with enough fidelity to reconstruct an incident, and monitoring that will actually tell you one is happening.
The part organizations skip is making the baseline mechanical. Governance rules can assert that every API declares a security scheme, that no operation is left unauthenticated by accident, that no schema permits unbounded input, that error responses are documented. Those checks run in the pipeline on every change and cost nothing after you write them. That is a multi-layered approach — design-time rules, runtime enforcement, and validation — aimed squarely at the OWASP API risks.
The uncomfortable truth underneath all of it: investment in API security keeps falling short because there is so little accountability when a breach happens. The organizations that do it well are the ones that decided not to wait for that to change.