APIs now carry more sensitive data than traditional web pages. They power mobile apps, single-page applications, integrations, and microservices. Yet API security consistently lags behind web application security. The OWASP API Security Top 10 exists for a reason — these vulnerabilities appear on virtually every API assessment.
Broken Object-Level Authorization (BOLA)
The most prevalent API vulnerability is also the simplest. An API returns data based on an object ID in the request. Change the ID, get someone else's data. It sounds almost too basic to be real, but BOLA appears in the majority of API security assessments.
GET /api/v1/users/1337/orders
Authorization: Bearer valid-token-for-user-42
// If the API doesn't verify that user 42 owns user 1337's orders,
// every user's order history is exposed.The root cause is checking authentication (is this a valid user?) without checking authorization (is this user allowed to access this specific resource?). The fix is conceptually simple but operationally complex across hundreds of endpoints.
Missing Rate Limiting: Brute Force Paradise
APIs without rate limiting are vulnerable to credential stuffing, brute force, and enumeration attacks at machine speed. An attacker with a list of breached credentials can try thousands of login attempts per second against an unprotected /api/auth/login endpoint.
But rate limiting failures go beyond login. Consider:
- Password reset endpoints that confirm whether an email exists
- Search endpoints that can be used to enumerate all records
- File upload endpoints that can be abused for storage
- SMS/email sending endpoints that can be weaponized for spam
Excessive Data Exposure
APIs frequently return entire database objects and rely on the frontend to display only relevant fields. The response from /api/user/profile might include the user's email, name, and profile picture in the UI — but also their hashed password, internal user ID, role flags, and creation timestamp in the raw JSON.
Attackers don't use your frontend. They read the raw API response. Every extra field is potential intelligence for further attacks.
Mass Assignment
When an API accepts a JSON body and maps it directly to a database model, attackers can include fields they shouldn't be able to set:
PUT /api/user/profile
{
"name": "Normal User",
"email": "[email protected]",
"role": "admin",
"subscription_tier": "enterprise"
}If the backend blindly merges the request body into the user object, the attacker just escalated their privileges. This vulnerability is endemic in frameworks that favour convention over configuration.
Broken Function-Level Authorization
Administrative API endpoints are often "hidden" rather than protected. They don't appear in the public documentation, but they exist in the codebase. Attackers discover them through JavaScript source maps, mobile app decompilation, or simply guessing common patterns like /api/admin/users.
Security through obscurity is not a control. Every endpoint must independently verify the caller's authorization level.
The API Sprawl Problem
Modern applications often have more API endpoints than anyone on the team can enumerate. Legacy versions (/api/v1/) remain active alongside current versions. Internal APIs are accidentally exposed to the internet. Documentation drifts from reality. The result is an attack surface that grows silently.
ShieldReport helps you understand your domain's external posture, identifying exposed endpoints, missing security headers on API responses, and configuration weaknesses that make API exploitation easier.