API Attacks — OWASP API Top 10

Why API Attacks Are the New Norm

Modern applications are API-driven. Every mobile app, single-page application, and third-party integration communicates via APIs. Traditional web application firewalls are designed for HTML forms and URL parameters — API traffic uses JSON/XML bodies, varied HTTP methods, and often lacks the referrer or user-agent patterns that WAFs expect.

• APIs are a direct path to backend data. Authentication, authorization, and input validation must be implemented at the API level — but they often lag behind the front-end application’s security controls.
• Traditional WAF rules often miss API attacks because the attack vector is in the JSON body, not in URL parameters.
• API gateways (AWS API Gateway, Azure API Management, Kong, Apigee) provide logging and rate limiting, but detecting abuse requires understanding API-specific patterns.

MITRE ATT&CK maps API exploitation to T1190 (Exploit Public-Facing Application) and T1195 (Supply Chain Compromise) — APIs are a public-facing entry point to backend systems.

OWASP API Top 10 Overview

API1: Broken Object Level Authorization (BOLA)

BOLA is the most common API vulnerability and the top risk in the OWASP API Top 10. It occurs when an API endpoint does not verify that the authenticated user is authorized to access the specific object they requested.

How BOLA Works

GET /api/v1/users/1234/profile
Authorization: Bearer token-for-user-1234

→ Returns Alice's profile (legitimate — user 1234 is accessing their own profile)

GET /api/v1/users/5678/profile
Authorization: Bearer token-for-user-1234

→ Returns Bob's profile (BOLA — user 1234 should not access user 5678's profile)

BOLA Attack Patterns

Detection — BOLA in API Gateway Logs

SPL query — detect sequential ID access from a single session:

index=api_gateway
| rex field=uri_path "/(?:users|accounts|profiles|invoices|orders|documents)/(?<object_id>\d+)"
| stats dc(object_id) as unique_objects, count as total_calls by client_ip, user_id, user_agent
| where unique_objects > 10
| eval alert = "MEDIUM — BOLA enumeration: " . client_ip . " accessed " . unique_objects . " different object IDs"
| table _time, client_ip, user_id, unique_objects, total_calls, user_agent, alert
| sort - unique_objects

KQL query — detect BOLA via Azure API Management logs:

ApiManagementGatewayLogs
| where Url matches regex @"\/api\/[^\/]+\/(users|accounts|orders)\/\d+"
| summarize UniqueObjects = dcount(Url), TotalCalls = count() by CallerIp, UserId
| where UniqueObjects > 10
| project TimeGenerated, CallerIp, UserId, UniqueObjects, TotalCalls

API2: Broken Authentication

API authentication failures include weak token generation, missing authentication on endpoints, and improper session management.

Common API Authentication Issues

Detection — API Authentication Issues

index=api_gateway
| search http_method="POST" uri_path="/api/*login*" OR uri_path="/api/*auth*" OR uri_path="/api/*token*"
| stats count by client_ip, uri_path, response_code, user_agent
| where count > 100
| eval alert = "HIGH — " . count . " auth attempts from " . client_ip . " — possible credential brute force"
| table _time, client_ip, uri_path, count, alert
| sort - count

API3: Broken Object Property Level Authorization (Mass Assignment)

Mass assignment (also called auto-binding) occurs when an API endpoint binds client-provided data directly to internal objects without filtering which fields can be modified.

How Mass Assignment Works

The API accepts a JSON body and saves it to a database object directly:

POST /api/users/register
Legitimate: {"username": "alice", "email": "alice@example.com", "password": "s3cur3"}

Attack:     {"username": "alice", "email": "alice@example.com", "password": "s3cur3", "role": "admin", "is_admin": true}

→ The API saves all fields — Alice is now an admin

Mass Assignment Attack Patterns

Detection — Mass Assignment

index=api_gateway
| search http_method="POST" OR http_method="PUT" OR http_method="PATCH"
| search request_body IN ("*role*:*admin*", "*is_admin*:true", "*verified*:true", "*is_verified*:true", "*permissions*:*admin*")
| stats count by client_ip, uri_path, request_body
| eval alert = "HIGH — Possible mass assignment to " . uri_path . " from " . client_ip
| table _time, client_ip, uri_path, request_body, alert

API4: Unrestricted Resource Consumption

APIs that do not enforce rate limiting, pagination, or payload size limits allow attackers to exhaust server resources or extract large datasets.

Attack Vectors

Detection — Resource Exhaustion

KQL query — detect large API responses (data extraction):

ApiManagementGatewayLogs
| where ResponseBodySize > 5000000 (5 MB responses)
| summarize count() by CallerIp, Url, ResponseBodySize
| where count_ > 10
| project TimeGenerated, CallerIp, Url, ResponseBodySize, count_

SPL query — detect GraphQL depth attacks:

index=api_gateway source="graphql"
| eval query_depth = len(mvfilter(match(query, "\{"))) (count of opening braces)
| where query_depth > 10
| eval alert = "HIGH — GraphQL query depth " . query_depth . " from " . client_ip . " — possible recursive DoS"
| table _time, client_ip, query_depth, query
| sort - query_depth

API5: Broken Function Level Authorization

BFLA occurs when API endpoints do not enforce role-based access. An authenticated user can call admin-level API functions.

BFLA Examples

Detection — BFLA

index=api_gateway
| search http_method IN ("DELETE", "POST", "PUT", "PATCH") uri_path IN ("*/admin/*", "*/config/*", "*/permissions/*", "*/roles/*", "*/delete*")
| stats count by client_ip, user_id, http_method, uri_path, response_code
| where response_code = 200
| eval alert = "HIGH — " . user_id . " called admin function " . http_method . " " . uri_path . " — verify authorization"
| table _time, client_ip, user_id, uri_path, response_code, alert

API6: Unrestricted Access to Sensitive Business Flows

Attackers abuse business-critical API endpoints at high volume — credential stuffing (login API), coupon abuse (discount API), vote manipulation, or reservation bots.

Detection — Business Flow Abuse

Key indicators:

• High call volume to a single endpoint from a single IP or IP range
• Low time between requests — faster than humanly possible
• Repetitive request patterns with incremental changes (sequential IDs, cyclic values)
• Call volume that spikes and stays elevated — not bursty like legitimate traffic

SPL query — detect credential stuffing via login API:

index=api_gateway
| search uri_path IN ("*/login*", "*/auth*", "*/token*")
| stats count by client_ip, uri_path, bin(_time, 60s)
| where count > 20 (20 login attempts per minute = credential stuffing)
| eval alert = "HIGH — " . count . " login attempts in 60s from " . client_ip . " — credential stuffing"
| table _time, client_ip, uri_path, count, alert

API Specific Detection Techniques

API Gateway Logs

API gateway logs (AWS API Gateway, Azure API Management, Kong, Nginx, Cloudflare) are the primary detection source. Key fields:

JSON Schema Validation

API gateways can validate JSON payloads against a schema. Schema validation catches:

• Extra fields in the request body (mass assignment attempts)
• Wrong data types (string instead of number, null in required fields)
• Fields outside allowed ranges (negative amounts, future dates)
• Missing required fields (bypassing security-critical parameters)

API Attack Investigation Workflow

Phase 1: Identify Which API Endpoint Was Targeted

Phase 2: Determine Data Exposure

Phase 3: Containment

Related

• Web Application Attacks — SSRF, CSRF, Command Injection, Path Traversal, IDOR — detection and response for T1190 techniques
• Container and Kubernetes Threats — detection and response for T1611, T1525, T1574.002 techniques
• Kill Chain — covers the kill chain concepts
• OSI Model — covers the osi model concepts
• Metasploit — detection and response for T1203 techniques

Sources

• OWASP API Security Top 10
• OWASP API Security Project — Cheat Sheets
• PortSwigger — API Testing
• MITRE ATT&CK T1190
• Microsoft — API Security Best Practices