APIs power everything — mobile apps, SPAs, microservices, third-party integrations. They're also where we find the most critical vulnerabilities. Unlike traditional web pages, APIs often lack the UI-level protections that developers take for granted.
Here are the blind spots we see repeatedly.
The Scale of the Problem
83%
of Web Traffic Is API
91%
of Orgs Had API Incident
#1
Attack Vector for Data Breaches
3x
More API Endpoints Than Pages
1. Broken Object-Level Authorization (BOLA)
The single most common API vulnerability — and the most dangerous.
Authenticate as User A
Attacker creates a legitimate account or steals low-privilege credentials
Observe API request pattern
Notes the API calls: GET /api/v1/users/123/orders
Change the object ID
Modifies the request to GET /api/v1/users/456/orders
Access User B's data
If the API only checks authentication (not authorization), it returns another user's orders
🛑Why It's So Common
Most frameworks handle authentication well out of the box. But authorization — checking that User A can access Resource X — must be implemented by developers for every endpoint. One missed check is all it takes.
What to do:
- Implement authorization checks at the data access layer, not just the route level
- Use the authenticated user's session to determine data access, never trust client-supplied IDs alone
- Write authorization tests for every endpoint with multiple user roles
2. Excessive Data Exposure
APIs often return entire database objects and rely on the frontend to filter what's shown to the user.
Excessive Data Exposure Pattern
The Problem
API returns full user object: id, name, email, password_hash, ssn, internal_role, admin_notes. Frontend only displays name and email.
The Attack
Attacker inspects API responses directly (browser DevTools, Burp Suite) and sees all fields — including sensitive data the UI was hiding.
The Fix
API should return only the fields the consumer needs. Use response DTOs/serializers that explicitly whitelist fields per endpoint and per user role.
3. Broken Function-Level Authorization
Different from BOLA — this is about accessing functions you shouldn't have access to, not just data.
Common patterns we find:
- Regular users can access
/api/admin/usersby simply knowing the URL - DELETE methods enabled on resources where users should only have GET access
- Internal microservice endpoints exposed on the public API gateway
- Debug or test endpoints left in production (
/api/debug/reset,/api/test/bypass-auth)
67%
APIs with Hidden Admin Routes
43%
Missing Method Restrictions
31%
Internal Endpoints Exposed
22%
Debug Endpoints in Prod
4. Mass Assignment
When APIs accept JSON bodies and automatically bind them to database models, attackers can set fields they shouldn't have access to.
Normal profile update
User sends: PUT /api/profile with name and email in the body
Attacker adds extra fields
Sends the same request but adds role: admin and is_verified: true to the JSON body
Server blindly assigns all fields
If the API uses Model.update(req.body) without whitelisting, the attacker is now an admin
⚠️Framework Defaults Are Dangerous
Many frameworks (Rails, Django, Express with Mongoose) will happily accept and save any field you send unless you explicitly whitelist allowed fields. Always use allowlists, never blocklists.
5. Rate Limiting and Resource Exhaustion
APIs without proper rate limiting are vulnerable to:
- Credential stuffing — Trying millions of username/password combinations
- Data scraping — Extracting entire databases one page at a time
- Denial of service — Sending expensive queries (deep GraphQL nesting, large file uploads, complex searches)
- Brute force — Guessing OTPs, reset tokens, or API keys
Weak Rate Limiting
- •Global rate limit only (1000 req/min per IP)
- •No rate limit on authentication endpoints
- •Rate limit by IP only (bypassable with rotating proxies)
- •No query complexity limits on GraphQL
Proper Rate Limiting
- •Per-endpoint rate limits based on sensitivity
- •Strict limits on login, reset, and OTP endpoints
- •Rate limit by user account + IP + API key
- •Query depth and complexity limits on GraphQL
6. Improper Inventory Management
You can't secure what you don't know exists.
What we find during recon:
- Old API versions still running (
/api/v1/with no auth, while/api/v2/has proper auth) - Swagger/OpenAPI docs exposed in production with full endpoint details
- Internal APIs accessible from the internet
- Partner/webhook endpoints with hardcoded API keys
- Deprecated endpoints that still work but aren't monitored
ℹ️Why AI Recon Matters Here
Our AI agents enumerate every API endpoint — including ones the development team has forgotten about. In one recent audit, we found 47 undocumented endpoints, 12 of which had no authentication at all.
7. Security Misconfiguration
- CORS set to
Access-Control-Allow-Origin: *on authenticated APIs - Missing
Content-Typevalidation (sending XML to a JSON endpoint to trigger XXE) - Verbose error messages returning stack traces and database details
- Missing TLS on internal API communication
- Default credentials on API management dashboards
The Fix: Layered API Security
Inventory
Know every API endpoint, version, and consumer
Authenticate
Strong auth on every endpoint — no exceptions
Authorize
Per-resource, per-action authorization checks
Validate
Strict input validation and output filtering
How secure are your APIs? Get an API security audit — our AI maps your full API surface while human experts test authorization logic, business flows, and chained attack scenarios.