Five API Security Mistakes Almost Every Engineering Team Makes

APIs are the connective tissue of modern applications. They're also the most common entry point for attackers. Every penetration test report I've reviewed in the last three years has at least one API-layer finding rated high or critical. Most have several.

The patterns are remarkably consistent. These aren't exotic zero-days. They're basic architectural mistakes that teams repeat because nobody on the team was trained to recognise them.

1. Trusting the client to enforce authorization

This is the single most common API vulnerability in production applications. The frontend hides a button or a menu item based on the user's role. The API endpoint behind that button has no authorization check at all.

An attacker doesn't use your frontend. They call the endpoint directly. If your /api/admin/users endpoint returns data to anyone with a valid session token, your role-based access control is cosmetic.

The fix is straightforward: every API endpoint must verify the caller's permissions server-side, independently of whatever the client does. But "straightforward" doesn't mean "automatic." Developers need to be trained to think about authorization at the endpoint level, not the UI level.

2. Returning too much data

OWASP calls this Excessive Data Exposure, and it's endemic in applications built with ORMs. A developer writes an endpoint that returns a user object. The ORM serialises the entire database row — including the hashed password, internal account flags, and the user's email verification token.

The frontend only displays the user's name and avatar. But the full payload is visible in the network tab to anyone who opens DevTools. Attackers don't need DevTools — they have scripts.

The discipline is response shaping: explicitly defining which fields an endpoint returns, rather than dumping the model. This is a code pattern, and it's teachable. Teams that build this habit stop leaking data. Teams that don't will keep leaking data until a researcher or an attacker tells them.

3. Using sequential IDs without ownership checks

If your endpoint is /api/invoices/1047 and changing it to /api/invoices/1048 returns someone else's invoice, you have an Insecure Direct Object Reference — IDOR. It's the most reliably exploitable class of API vulnerability because it requires zero sophistication. Change a number. Get someone else's data.

UUIDs make enumeration harder but don't fix the underlying problem. The fix is an ownership check: before returning a resource, verify that the authenticated user has the right to access it. This sounds obvious, but in a codebase with 200 endpoints built by a team of 15 developers over two years, it's the check that gets missed.

Hands-on training that puts a developer in front of an IDOR-vulnerable API and asks them to exploit it — then fix it — builds the reflex faster than any documentation.

4. Missing or broken rate limiting

Authentication endpoints without rate limiting are an open invitation for credential stuffing. Password reset endpoints without rate limiting leak information about which email addresses exist in your system. Search endpoints without rate limiting let competitors scrape your catalogue.

Rate limiting is an infrastructure concern, but the decision about which endpoints need it and at what thresholds is an application security decision. Developers who understand the threat model make better decisions here than developers who are told to "add rate limiting" without context.

The common mistake is applying a single global rate limit and calling it done. Effective rate limiting is endpoint-specific: your login endpoint needs a much tighter limit than your product listing endpoint, and the response to hitting the limit matters too — a 429 that reveals timing information can be worse than no limit at all.

5. Logging sensitive data in API responses

This one shows up in incident response more than in penetration testing. A team enables request/response logging for debugging. The logs capture full API payloads, including authentication tokens, credit card numbers, or personally identifiable information. Those logs go to a centralised logging platform with broad read access across the engineering team.

Now your secrets aren't just in your database — they're in Datadog, Splunk, or CloudWatch, with a different access control model and a different retention policy. An attacker who compromises a developer's logging dashboard gets a searchable archive of sensitive data.

The pattern to train on is log hygiene: sanitising sensitive fields before they reach the logging layer, using structured logging that makes redaction systematic rather than ad hoc, and understanding that observability tools are part of your attack surface.

The common thread

None of these are novel. None require deep security expertise to fix. They require developers who have been trained to think about APIs from an attacker's perspective — not just a consumer's perspective.

That shift in perspective is the difference between a team that ships secure APIs and a team that ships APIs that happen to work until someone tests them adversarially. Security training that puts developers inside these scenarios — exploiting the flaw, then fixing it — builds that perspective faster than anything else.