Last month, a fintech company exposed 340,000 customer records. The vulnerability? An API endpoint that returned user data based on a sequential ID. Change the number, get someone else's data. No auth check. No rate limiting.

This company had a security team and SOC 2 compliance. Didn't matter.

APIs Are the New Attack Surface

Your mobile app, web frontend, partner integrations, microservices - they all talk through APIs. That's where attackers look first.

The Facebook scrape from May 2025 proves it. Attackers found an API with weak authentication and no rate limiting. They hammered it with a script. 1.2 billion records exposed. The largest breach in Meta's history wasn't some sophisticated attack - it was someone iterating through an endpoint.

What's Actually Breaking

Broken Object Level Authorization (BOLA) accounts for 40% of API attacks. User A changes an ID in the URL and gets User B's data. Simple. Devastating.

Broken Authentication means APIs that don't validate tokens properly, accept expired JWTs, or skip re-authentication for sensitive actions.

Excessive Data Exposure happens when your API returns 47 fields when the client needs 3. One of those extra fields is isAdmin. You see the problem.

The Fixes That Actually Work

Validate server-side. Every input. Every parameter. If your authorization logic lives in the client, you don't have authorization.

Use real authentication. OAuth 2.0 with short-lived tokens. PKCE for public clients. API keys alone are not a security strategy - I've seen them committed to public repos, shared in Slack, hardcoded in mobile apps.

Rate limit intelligently. Different limits for different endpoints. Stricter on auth endpoints. This makes reconnaissance expensive enough that attackers move on.

Return only what's needed. Client needs three fields? Return three fields. Not the entire object.

Log everything. User, endpoint, parameters, response code. When something goes wrong, you need to know what happened.

The Real Problem

API security fails because it's organizationally inconvenient. Security reviews slow releases. Rate limiting requires infrastructure. So teams ship fast and promise to fix it later. Later becomes never.

If you're thinking "we should audit our APIs," you're right. Start with auth endpoints. Check if User A can access User B's data by changing IDs. Test your rate limits. Review what your responses actually return.

Not glamorous work. But it's what keeps you out of breach headlines.