APIs change framework, language and architecture, but the findings that show up most in penetration testing have stayed roughly the same for years. It's not a tooling problem — these patterns come from design decisions, not one-off bugs, which is exactly why they keep repeating from project to project. Here's a direct rundown of the five that show up most, in the order they tend to get exploited first.
1. Broken Object Level Authorization (BOLA)
By far the most common finding in API penetration testing. The route authenticates the user correctly, but never checks whether that user is actually allowed to touch the specific object they're requesting. Swap a numeric ID or a UUID in the URL and suddenly you can view or modify someone else's data — that's the classic symptom. It happens because authorization checks tend to be scattered across dozens of endpoints, and it's easy to miss one.
2. Excessive data exposure
The API returns the full database object and leaves the front-end to decide what to display. Works fine until someone inspects the raw response and finds a password hash, an internal token, a national ID, or another user's data that should never have left the backend. It's one of the easiest findings to confirm and, at the same time, one of the easiest to prevent: filter the response on the server, never trust the client to hide what it shouldn't see.
3. Missing rate limiting
A login endpoint, a password reset flow, or a search endpoint with no attempt limit opens the door to brute force, user enumeration and cost abuse (in APIs that call pay-per-request services, like SMS delivery or AI generation). Rate limiting is cheap to implement and rarely a priority — until it shows up in a pentest report.
4. Weak JWT validation
A JWT accepted without validating the signature, accepting the 'none' algorithm, or validating the signature while ignoring expiration. Long-lived tokens with no revocation mechanism also show up a lot — if one leaks, it stays valid until it expires, not until someone notices.
- Signature always validated server-side, never just decoded
- Algorithm fixed explicitly, never read from the token's own header
- Short expiration, with a longer-lived, revocable refresh token
5. Overly verbose error messages
A stack trace, framework version, SQL query or file path inside a 500 error body doesn't compromise anything on its own, but it significantly shortens the path for someone mapping the attack surface. It's free reconnaissance, handed over by the application itself.
Why this keeps happening
None of these five are sophisticated. All of them are well documented — four are on the OWASP API Security Top 10. The pattern we see is that traditional automated scanning catches #5 reliably and #3 reasonably well, but #1, #2 and #4 depend on understanding the API's business logic — who should be allowed to see what — which is exactly what separates a scan from a penetration test.