Last night I attended a great talk on API security by Dan Barahona. 83% of internet traffic is API calls, yet API security is often treated as an afterthought. Here are my notes.
Real-World Breaches
The talk walked through a series of high-profile API breaches, and the pattern was clear: most of them were embarrassingly simple to exploit.
- LinkedIn — entire database scraped via an unsecured API
- McDonald's job app — an attacker could query any applicant by incrementing a
lead_idparameter (classic BOLA) - Duolingo — an endpoint accepted an email as a selector and returned all user data for that account, exposing 2.6M emails and names
- Venmo — last 10 transactions were supposed to be anonymized, but the API returned un-anonymized data. Don't use the front end as your filter.
- Formula 1 — someone added
"role": "admin"to an API request and got admin access - Trello — same email-selector issue as Duolingo
- Bumble — a mess: unauthenticated endpoints, BOLA, location triangulation via three accounts, and users could upgrade their own account type via an unsecured POST
- Instagram — password reset used a 6-digit code with a limit of 200 guesses per IP. With enough IPs, 1 million guesses was doable in 10 minutes. Tests all passed; nobody thought to test bypass scenarios.
Common Vulnerabilities
The talk focused on vulnerabilities that don't get enough attention:
- BOLA (Broken Object Level Authorization) — can you access another user's data by changing an ID?
- RBAC issues — roles not enforced at the API layer
- Mass Assignment — APIs accepting fields they shouldn't
- Logic Flaws — the API does what it's supposed to, just not in the way intended
- API7: Server-Side Request Forgery
- API8: Security Misconfiguration
- API9: Improper Inventory Management — attackers will probe old API versions
- API10: Unsafe Consumption of APIs — a third-party API being safe is not a given
A key insight: lots of security effort goes into the front end, but the API behind it may be wide open. Over-permissioned APIs are easier to build with but very dangerous.
API Attacks Look Legitimate
Unlike SQL injection (which is noisy and easy to detect), proper API attacks look like valid traffic. A WAF can't tell whether a user is authenticated or authorized to access a resource. That makes detection hard and prevention critical.
AI and MCP
The talk touched on how the threat landscape is evolving:
- Old model: mobile app → API → backend
- With AI: mobile app → AI → API → backend
- Now: user → Claude → MCP → API call
As agents consume APIs instead of humans, the attack surface changes. You need to understand who (or what) your API consumers are and guardrail accordingly.
How to Defend
- Rate limits are a nice extra, but they don't make you secure on their own
- OAuth 1/2/3 misconfigurations are responsible for 90% of broken auth, broken authorization, and excess data exposure issues
- Threat modeling helps you prioritize — don't burn time on low-risk, low-damage issues
- Get dev and security working together; all current hacks are logic attacks, not technical exploits
- Monitor API error codes — a spike in errors can signal an attack in progress
- Establish and agree on API standards across your team
- Add a
security.txtwith asecurity@yourdomain.comcontact and give researchers 90 days to fix before disclosure
Practice
Open Vault Bank is an intentionally vulnerable bank app you can practice against. Hit the reset button before you start — it's a public environment.
Resources
The speaker, Dan Barahona, runs API Sec University — free API security training and certifications worth checking out.