API Security (REST and GraphQL): technical protection guide, OWASP API Top 10 and pentesting

Why APIs are the leading attack vector today

APIs have gone from an integration detail to the dominant attack surface of modern applications. In fintechs, mobile apps, crypto and e-commerces, practically all business logic — payments, balances, KYC, orders, transfers — travels through REST or GraphQL endpoints consumed by SPA front-ends, native apps and B2B partners. Each exposed endpoint is a direct door to the most sensitive data and operations, without the intermediary of a server-side rendering that historically filtered access.

The shift of risk to the API layer has three structural causes. First, the explosion in the number of endpoints: microservices and BFFs (Backend for Frontend) multiply internal and external APIs faster than teams can inventory them. Second, the programmatic nature of consumption: an attacker needs neither a browser nor social engineering — just an HTTP client, a token and the ability to iterate parameters (IDs, filters, pagination) at high speed. Third, authorization flaws that generic tools do not detect: a signature-based WAF does not know that user A should not access user B's account, because the request is syntactically perfect.

In fintechs the impact is immediately financial and regulatory. A BOLA flaw (broken authorization at the object level) that allows changing account_id in the URL and reading another customer's statement is, simultaneously, a personal-data leak under the LGPD, a breach of Open Finance requirements and a direct fraud risk. APIs also concentrate fraud automation: credential stuffing, coupon abuse, price scraping and mass creation of fake accounts almost always occur via API, not through the web interface. Treating API security as a problem separate from application security — with its own inventory, authorization and testing — is no longer optional.

OWASP API Security Top 10 2023: the flaws that dominate the risk

The OWASP API Security Top 10 2023 is the reference framework for classifying API risks. Unlike the traditional web Top 10, it was rewritten to reflect API-specific flaws, with an emphasis on authorization. The full list: API1 Broken Object Level Authorization (BOLA), API2 Broken Authentication, API3 Broken Object Property Level Authorization (BOPLA), API4 Unrestricted Resource Consumption, API5 Broken Function Level Authorization, API6 Unrestricted Access to Sensitive Business Flows, API7 Server Side Request Forgery (SSRF), API8 Security Misconfiguration, API9 Improper Inventory Management and API10 Unsafe Consumption of APIs.

BOLA (API1) has been the number-one flaw since 2019 and remains at the top. It occurs when the API validates that the user is authenticated but does not verify whether that specific user is entitled to the requested object. Example: GET /api/v2/accounts/1042/statement returns the statement without checking whether the token belongs to the owner of account 1042 — changing the ID to 1043 leaks someone else's data. It is the basis of IDOR (Insecure Direct Object Reference). The defense is not to hide the ID, but to enforce an ownership check on the server at every access to every object.

API2 (Broken Authentication) covers predictable tokens, poorly validated JWT, missing expiration, weak password recovery and login endpoints without brute-force protection. API3 (BOPLA) merged the former Excessive Data Exposure and Mass Assignment: the API returns sensitive fields the client should not see (national ID, password hash, internal flags) or accepts fields the client should not write (is_admin, balance) by accepting the whole object without a property allow-list.

API4 (Unrestricted Resource Consumption) deals with the absence of limits — no rate limiting, no payload size cap, no mandatory pagination — leading to denial of service and uncontrolled costs (especially severe in GraphQL with deeply nested queries). API5 (Broken Function Level Authorization) is access to administrative functions by ordinary users, such as calling DELETE /api/admin/users without an admin role. API6 covers abuse of legitimate flows (ticket purchases, account creation) at automated scale. API7 (SSRF) occurs when the API fetches a client-supplied URL without validation, allowing it to reach internal services and cloud metadata. API8, API9 and API10 cover insecure configuration, poor inventory (shadow/zombie APIs) and unsafe consumption of third-party APIs.

Authentication and authorization: OAuth2, OIDC, JWT, mTLS and scopes

Authentication and authorization are distinct problems and both must be solved on the server. Authentication answers who the caller is; authorization answers what they can do and over which objects. In APIs, the standard is OAuth 2.0 (with OpenID Connect for identity) issuing short-lived access tokens. Use the Authorization Code Flow with PKCE for mobile apps and SPAs, and Client Credentials for service-to-service communication. Avoid the Implicit Flow and Resource Owner Password Credentials, both deprecated by current OAuth practice.

JWT is secure when validated correctly, and insecure by default if it is not. The minimum rules: reject the none algorithm; pin the expected algorithm on the server instead of trusting the alg header (this prevents the RS256→HS256 confusion attack); validate the signature, issuer (iss), audience (aud) and expiration (exp) on every request; keep access tokens short (5 to 15 minutes) and use rotated refresh tokens with the ability to revoke. JWT is stateless and not trivially revocable — for sensitive sessions, maintain a denylist of revoked tokens or prefer reference (opaque) tokens resolved against an introspection server.

mTLS (mutual TLS) raises the identity guarantee in service-to-service traffic and in regulated integrations: both sides present a certificate, and the connection is established only between provably authorized parties. It is the standard for Open Finance in Brazil and for internal microservice meshes (service mesh), where it complements OAuth with cryptographic workload identity. OAuth scopes restrict what a token can do in a coarse way (payments:read vs payments:write); they are necessary but not sufficient.

The piece that fails most is object-level authorization. A scope grants the ability to read payments; it does not verify whether this payment belongs to this user. Every operation on an identifiable object needs an ownership or policy check on the server, derived from the token's identity and never from a client-controlled parameter. Centralize that decision in an authorization layer (for example, a policy engine like OPA/Rego or an ABAC/ReBAC middleware) to avoid the scattered, inconsistent checks that give rise to BOLA.

Rate limiting and abuse protection

Rate limiting controls the frequency of calls and is the direct defense against API4 (unrestricted resource consumption) and against fraud automation. Generic per-IP limits are easily bypassed with IP rotation and residential proxies; the robust approach applies limits across multiple dimensions — per consumer (client_id or authenticated user), per endpoint and per operation type — using algorithms such as token bucket or sliding window. High-cost or high-risk endpoints (login, OTP, account creation, search, export) should have stricter limits than trivial reads.

Beyond the numeric limit, configure per-request resource caps: maximum payload size, maximum query depth and complexity (critical in GraphQL, where a single nested query can force thousands of resolutions and take down the backend), maximum number of items per page and execution timeout. In GraphQL, apply query cost analysis, depth limits and disable introspection in production to reduce the reconnaissance surface.

For business-flow abuse (API6), pure rate limiting is not enough: intent must be detected. Protect login and sensitive operations with defenses against credential stuffing — progressive lockout, adaptive CAPTCHA, device fingerprinting and anomalous-behavior detection (many distinct accounts from a single device, non-human timing patterns). Always respond with 429 Too Many Requests and Retry-After and quota (RateLimit-*) headers, and log limit-exceeded events as a signal for the SOC, as they often precede larger attack campaigns.

API gateway, WAAP and discovery of shadow and zombie APIs

The API gateway is the single entry point where authentication, TLS termination, routing, rate limiting and logging are centralized. Concentrating these functions in the gateway reduces inconsistency between services and creates an observation point for all traffic. On top of it, a WAAP (Web Application and API Protection) — the evolution of the classic WAF — adds API-specific protection: validation of conformance with the OpenAPI/GraphQL schema, per-consumer anomaly detection, bot blocking, application-layer DDoS mitigation and signal correlation to identify business-logic abuse that static signatures miss.

None of these defenses reach an endpoint the team does not know exists. Shadow APIs are undocumented or ungoverned endpoints — exposed by a forgotten deploy, a test environment in production or a microservice no one mapped. Zombie APIs are old versions (v1, v2-beta) that stayed online after being replaced, often without the patches and controls of current versions. Both correspond to API9 (Improper Inventory Management) and are a preferred target because they escape the gateway and the WAAP.

Discovery must be continuous, not a one-off inventory. Combine real-traffic analysis (passive discovery from gateway logs, network mirroring or agents) with active scanning of hosts and ranges, automatic OpenAPI specification generation from observed traffic and reconciliation against the official inventory to flag discrepancies. Each discovered API should have a recorded owner, data classification, version and deprecation date. Without a living inventory, API security coverage metrics are fictional.

Testing API security: API pentesting in practice

Automated scanners and generic DAST find configuration issues and classic injections, but are structurally blind to the main API flaws. BOLA, BOPLA and Broken Function Level Authorization are authorization-logic flaws: the request is valid, the status is 200, and only a tester who understands the business model knows that user A should not have accessed user B's object. That is why API pentesting is mostly manual and context-driven, complemented by automation.

An API pentest run by Decripte follows a method aligned with the OWASP API Top 10 2023. It starts with discovery and inventory (including shadow and zombie APIs) and with collecting the OpenAPI/GraphQL specification and the authentication flow. Next, it tests authorization with multiple accounts and roles in parallel: for each object accessible by user A, it attempts to access it with user B's token (BOLA), manipulates sensitive properties in writes (BOPLA/mass assignment) and attempts to invoke administrative functions with ordinary roles (BFLA).

The scope also covers authentication (JWT validation, expiration, brute force, OAuth flows and password recovery), resource consumption (absence of rate limiting, costly GraphQL queries), SSRF in fields that accept URLs, business-flow abuse and configuration (permissive CORS, improper HTTP verbs, error messages leaking stack traces, missing security headers). Each finding is delivered with a reproducible proof of concept, a severity classification and a concrete fix.

API security is a cycle, not an event. Integrate authorization tests and contract validation into CI/CD, run manual pentests at each relevant surface change and maintain continuous monitoring in the SOC. Decripte runs API pentests for fintechs and apps, helps implement the controls and maintains a 24x7 SOC with an SLA to contain a critical incident within 1 hour — because finding the flaw and containing its exploitation are parts of the same problem.

Passo a passo

1. Inventory and discover all APIs: generate the OpenAPI/GraphQL specification, map endpoints through traffic analysis and active scanning, and eliminate shadow and zombie APIs with a living inventory (owner, data, version, deprecation).
2. Implement strong authentication: OAuth2/OIDC with Authorization Code + PKCE for apps and SPAs, Client Credentials and mTLS between services, and short-lived access tokens with rotated, revocable refresh.
3. Enforce object-level authorization on the server: validate ownership of each object from the token's identity (against BOLA/IDOR), apply a property allow-list on writes (against mass assignment) and check roles on administrative functions.
4. Validate input and contract: reject payloads outside the OpenAPI/GraphQL schema, limit payload size, query depth and cost, and never expose sensitive fields in responses.
5. Apply rate limiting and abuse protection: limits per consumer and per endpoint, credential-stuffing defenses on login/OTP, and 429 responses with Retry-After logged as a signal for the SOC.
6. Protect the edge with an API gateway and WAAP: centralize TLS, auth and logging in the gateway, add schema validation, per-consumer anomaly detection, bot mitigation and application DDoS mitigation.
7. Test continuously: manual API pentesting aligned with the OWASP API Top 10 2023 with multiple accounts and roles, authorization and contract tests in CI/CD, and 24x7 monitoring with an incident response plan.

Perguntas frequentes