API Security Common API Threats and Attack Surfaces
Every API has multiple points where an attacker can attempt to cause damage. These points are called attack surfaces. Understanding what these surfaces are — and how attackers exploit them — is the foundation of every defensive strategy in this course.
This topic maps out the most common threats against APIs, explains how each attack works in plain language, and shows you the specific part of an API that each attack targets.
What Is an Attack Surface
An attack surface is any point where an attacker can interact with a system and potentially cause harm. For an API, the attack surface includes every endpoint, every parameter, every header, every data format the API accepts, and every external system the API connects to.
API Attack Surface Map:
┌──────────────────────────────┐
Client Apps ─────►│ API Gateway / Load Balancer │
(web, mobile, └──────────────┬───────────────┘
third-party) │
▼
┌──────────────────────────────┐
│ Authentication Layer │ ← Attack: stolen tokens, brute force
└──────────────┬───────────────┘
│
▼
┌──────────────────────────────┐
│ API Endpoints │ ← Attack: BOLA, injection, fuzzing
│ /users /orders /payments │
└──────────────┬───────────────┘
│
▼
┌──────────────────────────────┐
│ Business Logic │ ← Attack: workflow abuse, price tampering
└──────────────┬───────────────┘
│
▼
┌──────────────────────────────┐
│ Data Store / Database │ ← Attack: SQL injection, data scraping
└──────────────────────────────┘
Attackers probe every layer of this stack looking for the weakest point. A strong defence at one layer does not make up for a weak defence at another.
Threat 1: Broken Authentication
Authentication is the process of proving who you are. Broken authentication means the API fails to verify identity correctly, allowing attackers to pretend to be legitimate users.
Common Broken Authentication Scenarios
Scenario A: Weak API Keys Developer creates API key: "key123" Attacker guesses it or finds it in a public GitHub repository Result: Full access to the API using the stolen key Scenario B: No Token Expiry User logs in → gets a token valid for 10 years User's device is stolen 6 months later Attacker uses the still-valid token indefinitely Scenario C: Tokens in URLs Developer builds: GET /api/data?token=abc123secret Token appears in server logs, browser history, proxy logs Anyone with log access finds valid tokens
The damage from broken authentication is complete — once an attacker holds a valid credential, they have the same access level as the legitimate user. No other attack can bypass authentication more cleanly.
Threat 2: Broken Object Level Authorization (BOLA)
BOLA is the single most common API vulnerability in the world. It occurs when an API returns a resource to any authenticated user who asks for it by ID, without checking whether that user owns or is permitted to access that specific resource.
BOLA Attack Example — Food Delivery App: Normal flow: User Ravi (ID 201) logs in GET /api/orders/5501 → Returns Ravi's order ✓ BOLA attack: Attacker logs in as their own account (ID 999) Attacker changes order ID in the URL GET /api/orders/5502 → Returns Priya's order ✗ GET /api/orders/5503 → Returns Ananya's order ✗ GET /api/orders/5504 → Returns Arjun's order ✗ The API authenticated the attacker correctly. The API failed to check: "Does this user OWN order 5502?"
BOLA is the top-ranked vulnerability in the OWASP API Security Top 10 because it appears in almost every application that uses sequential or predictable resource IDs.
Threat 3: Injection Attacks
Injection attacks happen when an attacker sends malicious code or commands inside API parameters that the server then executes. The server mistakes attacker-controlled data for legitimate instructions.
SQL Injection via API
Normal search request:
GET /api/products?name=laptop
Server runs: SELECT * FROM products WHERE name = 'laptop'
Returns: list of laptops ✓
SQL Injection attack:
GET /api/products?name=laptop' OR '1'='1
Server runs: SELECT * FROM products WHERE name = 'laptop' OR '1'='1'
The condition '1'='1' is always true
Returns: EVERY product in the database ✗
More dangerous injection:
GET /api/products?name=laptop'; DROP TABLE products;--
Server runs: SELECT * FROM products WHERE name = 'laptop';
DROP TABLE products;
Deletes the entire products table ✗✗✗
Command Injection via API
API that pings a server to check availability:
POST /api/tools/ping
Body: { "host": "google.com" }
Server runs: ping -c 1 google.com ✓
Command injection attack:
POST /api/tools/ping
Body: { "host": "google.com; cat /etc/passwd" }
Server runs: ping -c 1 google.com; cat /etc/passwd
Returns: ping result + the server's user account list ✗
Threat 4: Sensitive Data Exposure
APIs frequently return more data than the client needs. When a server pulls a full database row and sends the entire object to the client, fields that should stay internal — password hashes, internal notes, billing information, personal identifiers — travel across the network unnecessarily.
API Response with Excessive Data Exposure:
GET /api/users/101
{
"id": 101,
"name": "Priya Sharma",
"email": "priya@example.com",
"plan": "premium",
"password_hash": "$2b$10$N9qo8uLOickgx2ZMRZo", ← Should NEVER be returned
"credit_card_last4": "4242", ← Sensitive
"ssn": "XXX-XX-1234", ← Very sensitive
"internal_risk_score": 72, ← Internal only
"admin_notes": "Flagged for review on 2024-03-01" ← Internal only
}
Even if the mobile app only displays the name and email, the full response travels over the network. Anyone who intercepts or proxies the connection sees everything. The fix is simple in principle: only return what the client actually needs.
Threat 5: Rate Limiting Absence
When an API imposes no limits on how many requests a client can make, attackers use automated tools to hammer the API at enormous scale. This enables several types of attacks.
What Happens Without Rate Limiting:
Attack Type 1: Credential Stuffing
Attacker has a list of 10 million leaked username/password pairs
Bot sends: POST /api/auth/login with pair 1 → fail
POST /api/auth/login with pair 2 → fail
POST /api/auth/login with pair 3 → SUCCESS
At 1000 attempts per second, 10 million pairs takes less than 3 hours
Attack Type 2: Data Scraping
Competitor sends: GET /api/products/1 → stores result
GET /api/products/2 → stores result
GET /api/products/3 → stores result
... up to GET /api/products/500000
In hours, they have your entire product catalogue and pricing
Attack Type 3: DDoS via API
Botnet sends 50,000 requests per second to /api/search?q=...
Server CPU maxes out at 100%
Legitimate users get timeouts
Service is effectively down
Threat 6: Security Misconfiguration
Security misconfiguration is one of the easiest vulnerabilities to introduce and one of the hardest to catch. It happens when an API is deployed with settings that prioritise convenience over security.
Common Misconfiguration Examples: ┌─────────────────────────────────────────────────────────────┐ │ Misconfiguration │ Risk │ ├─────────────────────────────────────────────────────────────┤ │ Debug mode on in prod │ Stack traces reveal source code │ │ │ paths, library versions │ ├─────────────────────────────────────────────────────────────┤ │ Default admin password │ admin/admin on management portal │ │ │ gives full control │ ├─────────────────────────────────────────────────────────────┤ │ CORS set to * │ Any website can make API calls │ │ │ using your logged-in session │ ├─────────────────────────────────────────────────────────────┤ │ HTTP instead of HTTPS │ Credentials and data travel in │ │ │ plain text │ ├─────────────────────────────────────────────────────────────┤ │ Verbose error messages │ "SQL error near 'users' table" │ │ │ tells attacker your DB structure │ └─────────────────────────────────────────────────────────────┘
Threat 7: Mass Assignment
Mass assignment occurs when an API automatically maps all fields from a request body to an internal object without checking which fields should be writable. Attackers inject extra fields that should be read-only.
Mass Assignment Attack — E-commerce Checkout:
Normal request body:
POST /api/checkout
{
"cart_id": 889,
"payment_method": "credit_card"
}
Attacker's request body:
POST /api/checkout
{
"cart_id": 889,
"payment_method": "credit_card",
"discount_percent": 100, ← Attacker-injected field
"final_price": 0.01 ← Attacker-injected field
}
If the server assigns all received fields to the order object:
Order total becomes 0.01 instead of the correct price.
Threat 8: Improper Asset Management
Large organisations run many API versions simultaneously. Version 1 of an API gets replaced by Version 2, but Version 1 is never decommissioned. It lives on a forgotten server, unmaintained and unpatched. Attackers find these old endpoints and exploit vulnerabilities that were fixed in the new version.
Improper Asset Management Diagram: Current production: https://api.example.com/v3/users ← Updated, secured, monitored Forgotten old versions: https://api.example.com/v1/users ← No auth required (old bug) https://api.example.com/v2/users ← Uses outdated library https://old-api.example.com/users ← On a server with no patches Attacker scans for old endpoints → finds v1 with no auth requirement Attacker accesses v1 freely → gets full user database
Threat 9: Server-Side Request Forgery (SSRF)
SSRF happens when an API fetches a URL that the client provides, without validating what that URL points to. An attacker provides a URL that points to internal systems the attacker should never be able to reach directly.
SSRF Attack Diagram:
Normal use case:
POST /api/fetch-preview
Body: { "url": "https://news.example.com/article/123" }
Server fetches the news article and returns a preview. ✓
SSRF attack:
POST /api/fetch-preview
Body: { "url": "http://169.254.169.254/latest/meta-data/" }
169.254.169.254 is the AWS EC2 metadata service.
It is only accessible from inside the cloud server itself.
From the attacker's laptop, it is unreachable.
But the server fetches it on the attacker's behalf.
Response includes: AWS secret keys, IAM roles, environment variables.
Attacker now has cloud credentials. ✗
Threat 10: Business Logic Attacks
Business logic attacks exploit flaws in what an API is designed to do, rather than in how it is built. The API works exactly as coded — but the business rules themselves have gaps that attackers take advantage of.
Business Logic Attack — Coupon Abuse: Normal design: Coupon code "SAVE10" gives 10% off one order per account. Business logic flaw: The API checks: "Has this coupon been used on this account?" → No → Apply it. But it applies the coupon before recording the use. Race condition exploit: Attacker sends 50 simultaneous requests for the same order with same coupon. All 50 requests check "has coupon been used?" at exactly the same moment. All 50 see "No" before any of them records "Yes". All 50 apply the discount. Result: 50 separate 10% discounts applied to one order.
The Attacker's Reconnaissance Process
Professional attackers do not attack blindly. They first map the attack surface systematically.
Attacker Reconnaissance Steps: Step 1: Discover Endpoints - Look for Swagger UI at /swagger, /api-docs, /openapi.json - Browse the JavaScript source code of the web app - Use tools like gobuster to brute-force common endpoint names - Check the Wayback Machine for old API documentation Step 2: Understand the Data Model - Call GET endpoints and study the response structure - Note all object IDs, user IDs, resource identifiers - Identify which fields are present in responses Step 3: Test Authentication - Try calling endpoints without any token → is 401 returned? - Try with an expired token - Try with a token from Account A to access Account B's data Step 4: Fuzz Parameters - Change numeric IDs up and down - Submit special characters in text fields - Submit unexpectedly large values - Add extra fields to request bodies Step 5: Map Business Workflows - Complete full user journeys (registration, purchase, withdrawal) - Look for steps that can be skipped or repeated - Look for workflows where client-side values (price, quantity) go to the server
How Defenders Map and Reduce the Attack Surface
Reducing the attack surface means removing unnecessary exposure. Every endpoint that does not need to exist publicly should not be public. Every field that does not need to be returned should not be returned. Every HTTP method that a resource does not support should return 405 Method Not Allowed.
Attack Surface Reduction Checklist: [ ] Maintain an inventory of ALL API endpoints (including old versions) [ ] Disable or remove endpoints that are no longer in active use [ ] Restrict HTTP methods per endpoint (if only GET is needed, reject POST) [ ] Return only the minimum fields needed in each response [ ] Disable debug endpoints and developer tools in production [ ] Remove or restrict API documentation access in production [ ] Implement authentication on every non-public endpoint [ ] Validate and sanitize all input before processing
Key Points
- An attack surface is every point where an attacker can interact with an API — endpoints, parameters, headers, and connected systems.
- Broken authentication lets attackers impersonate users. BOLA lets authenticated attackers access other users' data by changing resource IDs.
- Injection attacks (SQL, command) happen when API input is not sanitised before being used in queries or system commands.
- Sensitive data exposure occurs when APIs return full database objects instead of only the fields the client needs.
- SSRF lets attackers reach internal systems by tricking the API server into fetching attacker-controlled URLs.
- Business logic flaws exploit gaps in intended functionality, not implementation bugs — they require specific business knowledge to design and test for.