API Security: How Hackers Break Modern Applications

by

APIs are everywhere. Every mobile app, every SaaS product, every microservice talks through an API. And yet API security is consistently ranked as one of the most exploited attack surfaces in modern applications. The OWASP API Security Top 10 exists precisely because API vulnerabilities are uniquely dangerous — they give attackers direct access to business logic, sensitive data, and backend systems in ways that traditional web vulnerabilities often do not. This guide covers the real attacks, with real examples and concrete fixes.

Why APIs Are Different from Traditional Web Apps

A traditional web app renders HTML for browsers. An API returns raw data — JSON, XML — consumed directly by client code. This means there is no browser to enforce same-origin policy on the server side, no CSRF tokens built into forms, no UI to validate input visually. The entire security model must be implemented explicitly in the API itself. Many developers treat APIs as internal infrastructure and under-protect them accordingly.

Attack 1: Broken Object Level Authorization (BOLA/IDOR)

This is the #1 API vulnerability in the OWASP list — and the most commonly exploited in bug bounties. The attack is simple: an API endpoint accepts an object ID from the user and returns that object without checking whether the current user owns it.

# Vulnerable endpoint: GET /api/invoices/1042
# Attacker is logged in as user_B, changes ID to user_A's invoice
curl -H "Authorization: Bearer attacker_token" https://api.example.com/api/invoices/1041
# Returns user_A's invoice - BOLA vulnerability!

# Fix: always check ownership server-side
# Python/Flask example:
invoice = db.get_invoice(invoice_id)
if invoice.owner_id != current_user.id:
    return 403, "Forbidden"
return invoice

Attack 2: Broken Authentication

APIs often implement their own authentication rather than using proven frameworks. Common mistakes include weak JWT secrets, JWTs that never expire, API keys sent in query parameters (logged by every proxy), and missing rate limiting on auth endpoints.

# JWT with weak secret — crackable with hashcat
# Header.Payload.Signature
# If secret is "secret123", attacker can forge any token

# Test for weak JWT secrets with jwt_tool:
python3 jwt_tool.py eyJ... -C -d /usr/share/wordlists/rockyou.txt

# Test for algorithm confusion (none attack):
# Change alg to "none" and remove signature
import base64, json
header = base64.b64encode(json.dumps({"alg":"none","typ":"JWT"}).encode()).decode().rstrip('=')
payload = base64.b64encode(json.dumps({"user":"admin","role":"admin"}).encode()).decode().rstrip('=')
forged_token = header + "." + payload + "."

# Fixes:
# - Use RS256 (asymmetric) over HS256 where possible
# - Set short expiry (15 min access tokens, 7-day refresh tokens)
# - Never put API keys in URLs - use Authorization header
# - Implement rate limiting: max 5 failed auth attempts per minute

Attack 3: Excessive Data Exposure

APIs frequently return complete database objects and rely on the client to filter what it displays. This means sensitive fields — password hashes, SSNs, internal flags — travel to the client even though they are never shown in the UI. An attacker who intercepts or directly calls the API sees everything.

# Vulnerable: returns entire DB object
GET /api/users/me
{
  "id": 123,
  "username": "alice",
  "email": "alice@example.com",
  "password_hash": "$2b$12$...",   # NEVER expose this
  "internal_credit_score": 742,    # NEVER expose this
  "admin_notes": "flagged account" # NEVER expose this
}

# Fix: use explicit response schemas / serializers
# Python Pydantic example:
class UserResponse(BaseModel):
    id: int
    username: str
    email: str
    # password_hash, internal_credit_score NOT in schema = not returned

Attack 4: GraphQL-Specific Attacks

GraphQL APIs have a unique attack surface. Introspection queries let attackers map the entire API schema. Batching allows rate limit bypass. Deeply nested queries cause denial of service.

# Introspection attack — map entire schema without documentation
curl -X POST https://api.example.com/graphql   -H "Content-Type: application/json"   -d '{"query":"{ __schema { types { name fields { name } } } }"}'

# Query depth attack (DoS via deeply nested query)
{ user { friends { friends { friends { friends { name email } } } } } }

# Fixes for GraphQL:
# 1. Disable introspection in production
# 2. Implement query depth limiting (max depth: 5)
# 3. Set query complexity limits
# 4. Rate limit per IP and per authenticated user separately

Attack 5: Mass Assignment

Mass assignment happens when an API blindly binds all request parameters to a model object. If the model has an “isAdmin” field and the API accepts a JSON body, an attacker can simply add "isAdmin": true to their request.

# Vulnerable: API passes entire request body to ORM
PUT /api/users/profile
{"name": "Alice", "email": "alice@x.com", "isAdmin": true}
# ORM: User.update(request.body) -- sets isAdmin=true!

# Fix: explicitly whitelist allowed fields
allowed_fields = ['name', 'email', 'phone']
update_data = {k: v for k, v in request.body.items() if k in allowed_fields}
User.update(update_data)

Testing APIs: Essential Tools

  • Burp Suite — Intercept and modify API requests in real time, best for manual testing
  • Postman / Insomnia — API clients for crafting and replaying requests
  • jwt_tool — Test JWT vulnerabilities including weak secrets and algorithm confusion
  • ffuf — Fuzz API endpoints and parameters at high speed
  • nuclei — Template-based automated API security scanning
# Fuzz API parameters with ffuf
ffuf -u "https://api.example.com/api/users/FUZZ"   -w /usr/share/wordlists/SecLists/Discovery/Web-Content/api/objects.txt   -H "Authorization: Bearer your_token"   -mc 200,201,301

# Discover hidden API endpoints
ffuf -u "https://api.example.com/FUZZ"   -w /usr/share/wordlists/SecLists/Discovery/Web-Content/api/api-endpoints.txt   -mc 200,201,204,301,302,307,401,403

OWASP API Security Top 10 — Quick Reference

  1. BOLA — Missing object-level auth checks (most critical)
  2. Broken Authentication — Weak tokens, missing rate limiting
  3. Broken Object Property Level Auth — Exposing/modifying fields you should not
  4. Unrestricted Resource Consumption — No rate limits, DoS possible
  5. Broken Function Level Authorization — Admin endpoints accessible to regular users
  6. Unrestricted Access to Sensitive Business Flows — Buying items at $0, bypassing purchase flow
  7. Server-Side Request Forgery — API fetches attacker-controlled URL
  8. Security Misconfiguration — Default credentials, verbose errors, debug mode on
  9. Improper Inventory Management — Old API versions still running and unprotected
  10. Unsafe Consumption of APIs — Trusting third-party API responses without validation

API security is not optional in 2026. With microservices proliferating and mobile apps consuming dozens of endpoints, every missing authorization check is a potential breach waiting to happen. The good news: most API vulnerabilities are straightforward to fix once you know what to look for.