Field Notes: OWASP API Security Patterns

Most Traffic Is APIs. Most Reviews Aren't.

A line from the talk that lodged itself in my head: 83% of internet traffic is now API calls. The corollary is uncomfortable — most security reviews still treat APIs as an afterthought, downstream of the "real" web application.

The breach catalog the speaker walked through made the same point in a different way. None of these were exotic. They were the same five mistakes, repeated.

The Five Mistakes That Keep Showing Up

1. Broken Object Level Authorization (BOLA)

The McDonald's job portal exposed applicant data because the API trusted whatever ID was in the URL. Someone incremented a number and read someone else's application. This is the textbook BOLA failure: the endpoint authenticates the user but does not check that the user owns the object they asked for.

The fix is not subtle — every object lookup needs an authorization check tied to the requester. The reason it keeps happening is that this check is easy to forget on every new endpoint, and easy to skip when you are "just adding a small feature."

2. Email-Based Lookups That Return Everything

Duolingo and Trello both leaked millions of profiles because their APIs took an email and returned the matching user. The lookup itself was the vulnerability — not because emails are secret, but because the response was full of data the requester had no business seeing.

The pattern to avoid: any endpoint that takes a unique-ish identifier and returns a fat object. Unique identifiers are scrapeable. Fat objects multiply the blast radius.

3. Mass Assignment

The Formula 1 case was almost comical. The user object accepted any field the request sent, including a role field. Setting role: "admin" in the JSON body upgraded your account.

The fix is a one-line allow-list per endpoint. Every API framework has it. Every team eventually forgets to use it on at least one route.

4. Anonymized Data That Isn't

Venmo's transaction feed was technically anonymized, but the API responses included enough metadata to re-identify users from public-facing transactions. This is a category of bug where the privacy model is correct on paper and broken in the wire format.

If your privacy promise depends on what you don't send, the test is the API response, not the database schema.

5. Authentication Without Rate Limiting

Instagram's password reset flow used short codes with no meaningful rate limit. Brute force on a four-digit code is fast. The reset itself was the vulnerability, not the storage.

The pattern: any endpoint that accepts a guessable secret needs lockout, exponential backoff, or both. The cost is a few lines of middleware. The cost of skipping it is a CVE with your company's name on it.

What Defenders Actually Did About It

The talk's defensive playbook is unglamorous, which is a feature, not a bug:

Rate limits everywhere. On auth, on lookup, on submission. Default deny.
OAuth configurations reviewed. Most cloud OAuth bugs are misconfiguration, not protocol failure.
Threat modeling per endpoint. "What can the attacker who reaches this route do?" — written down, in the PR.
Cross-team collaboration. Security cannot be a separate department that hands you a checklist after the design is locked.
Monitoring error rates. A spike in 401s or 403s is a signal. So is a spike in 200s on a previously cold endpoint.
Published security contacts and disclosure timelines. Researchers want to help. Make it easy.

What I Took Away

API security is not a separate discipline you bolt on at the end. It is a property of how the endpoints are designed, one route at a time. The breaches in this catalog were not sophisticated. They were authorization checks that did not fire, allow-lists that did not exist, rate limits that were never set.

The boring controls are the ones that work. The sophisticated attacks are mostly clever exploitation of unsophisticated mistakes.

Resources

The speaker (Dan Barahona) pointed at API Sec University as a free resource for security training and certifications. Worth a look if you want to push the team's baseline up.