CyberAct
Publications/#API Security
Tag

API Security: attack surfaces & hardening

Understanding API Security

Definition

API Security covers the protection of application programming interfaces against unauthorized access, data leakage, and logic abuse. APIs expose backend functionality directly over HTTP, making them a primary attack surface in modern architectures. The OWASP API Top 10 formalizes the most critical risks: Broken Object Level Authorization (BOLA), Broken Authentication, Excessive Data Exposure, Lack of Resource Rate Limiting, and Mass Assignment are the most frequently exploited categories. REST and GraphQL endpoints differ structurally, but both suffer from identical root causes: missing authorization checks on individual objects, overly verbose responses, and absent input validation. A single unauthenticated endpoint can expose entire database tables through predictable resource identifiers. API versioning compounds the problem: deprecated v1 endpoints often remain active in production while security controls are only applied to v2 routes. Understanding these mechanisms is prerequisite to any meaningful defense or offensive assessment of microservices, mobile backends, and SaaS platforms.

Detection (Blue Team / SOC)

Detecting API abuse from a Blue Team perspective requires purpose-built observability beyond standard web application firewalls. First, enable structured logging at the API gateway layer, capturing full request paths, HTTP methods, response codes, payload sizes, and authenticated identity per request. Spikes in 401 and 403 responses on object-level endpoints indicate BOLA enumeration attempts. Unusual payload size increases on POST or PUT requests may reveal Mass Assignment exploitation attempts. Tools such as AWS CloudTrail, Kong logs, or Apigee analytics provide per-route telemetry. SIEM correlation rules should flag sequential access to incrementing numeric resource IDs from a single source IP within a short time window. For GraphQL, log every introspection query: attackers use introspection to map the full schema before crafting targeted payloads. JWT anomalies, including the 'none' algorithm, expired tokens still accepted by the backend, or tokens signed with weak secrets, are detectable by inspecting Authorization headers in proxy logs. Rate limiting violations and abnormal inter-request timing are valuable behavioral indicators that complement signature-based detection.

Exploitation & countermeasures (Red Team)

Red Team assessments targeting API Security begin with full endpoint enumeration using tools such as Burp Suite, FFUF, or Arjun for parameter discovery. BOLA testing involves substituting authenticated user IDs with those of other accounts in path parameters and request bodies, then observing whether the server enforces object ownership. Mass Assignment attacks inject undocumented fields into JSON bodies, attempting to escalate privileges by setting 'isAdmin' or 'role' properties the API fails to filter. JWT attacks include algorithm confusion (RS256 to HS256 switching), 'none' algorithm bypass, and brute-forcing weak HMAC secrets using tools like hashcat or jwt_tool. GraphQL-specific techniques include batching attacks to bypass rate limiting, nested query depth abuse to trigger denial of service, and field suggestion exploitation to recover hidden schema elements when introspection is disabled. Hardening countermeasures include enforcing strict object-level authorization middleware on every route, implementing schema validation with libraries like Pydantic or JSON Schema, disabling introspection in production GraphQL endpoints, rotating JWT signing keys regularly, and applying per-user rate limiting at the gateway rather than only at the IP level.

Articles about API Security

SOCIDOR in e-banking microservices: building a centralized authorization layer

Patching IDOR vulnerabilities endpoint by endpoint is a losing battle. Here's the architectural fix that actually scales.

Jun 22, 20266 min read