API Protection

API protection is the set of controls used to prevent, detect, and block API security threats like unauthorized access, authentication bypass, data exposure, and misconfiguration exploit across your REST, GraphQL, and gRPC endpoints.

API security is used as a general term to describe the overall discipline of securing APIs, which typically includes design review, testing, and API governance. API protection refers to runtime API threat protection or API detection and response, like blocking API attacks, stopping abuse, and continuous monitoring of API traffic.

Applications (both web and mobile), system integrations, and AI systems all rely on APIs to facilitate access to data and power functionality. Simply put, without APIs, an application or system doesn't function. Strong API protection reduces risks such as unauthorized access, account takeover (ATO), transaction fraud, and data leakage.

Common API attacks include broken object level authorization (BOLA) or insecure direct object reference (IDOR), broken authentication, broken object propery level authorization (BOPLA), broken function level authorization (BFLA), misconfiguration exploitation, unsafe third-party API consumption, injection, and business logic abuse.

Broken object level authorization (BOLA) or insecure direct object reference (IDOR) happens when an API fails to implement appropriate authorization checks throughout an authenticated user session. Identity and access management (IAM) controls are used to authenticate and authorize a user at the initiation of a session, but authorization checks must also be done continuously to avoid situations where a malicious party manipulates APIs calls in order to access another user’s objects or sensitive functionality.

API rate limiting can help reduce threats like bruteforcing, scraping, denial-of-service, and credential stuffing if implemented properly. Limits can be set on API request volume per user, token, IP address, or client fingerprint. Static rate limits may work for a time, but organizations typically need dynamic rate limits or must revisit limit policies continuously to address emerging threats or new attack campaigns. Rate limits may also need to be enforced at different ingress/egress points in a given architecture and dependent on API flows.

A web application firewall (WAF) is useful as a general-purpose application-layer (L7) control. WAFs are ideally suited for protecting web and mobile applications that communicate over HTTP and HTTPS, including client-side application code to server-side backend interactions, typically JavaScript (JS). While APIs often operate using the same standard web protocols, dedicated API protection adds REST/GraphQL awareness, schema validations, and stronger authorization-focused protections. WAFs also don't typically inspect or "understand" API-centric protocols like gRPC common in microservice architectures (MSA).

Always use strong API authentication and authorization, powered by community-vetted protocols like OpenID Connect (OIDC) and OAuth 2.0. Emphasize least privilege so users have access to only the data or functionality that's expected in normal user or employee flows. Also use tight scopes, particularly with federated auth and be cautious of redirects. Avoid using weak authentication material like static API keys alone, and pair with additional authentication factors (i.e., 2FA,MFA) for priviliged access. Access control policies must be continuously enforced at gateways and proxies, or even in the application runtime environment.

GraphQL API protection requires query depth limits, complexity limits, schema validations, strict authorization checks, and GraphQL-specific rate limiting to prevent data overfetching or abuse. Attackers may seek to abuse the GraphQL endpoint itself, or they abuse GraphQL as a proxy to backend functionality and data that the GraphQL endpoint aggregates normally.

API gateways and API gateways deployed as part of an API Management platform can enforce encrypted transport (e.g., TLS), access control policies, rate limits, usage limits, and intelligent routing. However, runtime API protection is still needed for advanced threat detection, abuse prevention, and full coverage of the OWASP API Security Top 10 risks.