API and service security
By the end of this module you will be able to:
- Identify and remediate BOLA vulnerabilities in API design
- Select appropriate API authentication patterns for different client contexts
- Design a rate limiting strategy that resists abuse without degrading legitimate traffic
- Describe the security functions of an API gateway with reference to named products
T-Mobile API breach, January 2023
T-Mobile: 37 million records via an unauthenticated API
In January 2023, T-Mobile disclosed that an attacker had accessed data for approximately 37 million customers via an unauthenticated API endpoint. The attacker queried customer data including names, billing addresses, email addresses, phone numbers, and account numbers.
The API endpoint had no authentication requirement, and its responses contained customer records that could be iterated by modifying a single object identifier in the request. No credentials were compromised. The attacker simply asked the API for data it should not have given out.
T-Mobile disclosed the breach to the SEC under its incident disclosure obligations. The fix required both adding authentication to the endpoint and adding object-level authorisation checks to verify the caller's relationship to the requested account identifier. Rate limiting on data retrieval endpoints, combined with anomaly detection on access patterns, would have detected the exfiltration far earlier than the several weeks it ran undetected.
OWASP API Security Top 10 (2023)
The OWASP API Security Top 10 was first published in 2019 and updated in 2023 to reflect the shift towards microservices, mobile backends, and third-party integrations. The ten categories are:
- API1: Broken Object Level Authorisation (BOLA) , object IDs not validated against caller's permission
- API2: Broken Authentication , missing or weak API authentication
- API3: Broken Object Property Level Authorisation , returning more object properties than permitted
- API4: Unrestricted Resource Consumption , no rate limiting
- API5: Broken Function Level Authorisation , access to admin endpoints by non-admin callers
- API6: Unrestricted Access to Sensitive Business Flows , automated abuse of business logic
- API7: Server-Side Request Forgery , internal network access via server
- API8: Security Misconfiguration , default credentials, verbose errors, unnecessary methods
- API9: Improper Inventory Management , undocumented shadow APIs and old versions still exposed
- API10: Unsafe Consumption of APIs , trusting third-party responses without validation
With an understanding of owasp api security top 10 (2023) in place, the discussion can now turn to bola: api1 in depth, which builds directly on these foundations.
BOLA: API1 in depth
Broken Object Level Authorisation (BOLA) is an API vulnerability where the server accepts a caller-supplied object identifier (such as a numeric record ID, UUID, or username) and returns or modifies the corresponding record without verifying that the authenticated caller has permission to access that specific object. BOLA is the API-specific name for horizontal privilege escalation.
A typical vulnerable endpoint: GET /api/v1/accounts/{accountId}/transactions. If the server validates the token but does not check whether accountId belongs to the authenticated user, any authenticated caller can retrieve any account's transactions by iterating the account ID. The T-Mobile 2023 case was BOLA without any authentication at all, making exploitation even simpler.
Remediation: (1) every object retrieval must check the authenticated principal's relationship to the object ID; (2) use indirect references where possible, mapping external-facing GUIDs to internal database IDs server-side so IDs are not sequentially guessable; (3) log all object access requests including principal, object ID, and outcome to enable anomaly detection.
With an understanding of bola: api1 in depth in place, the discussion can now turn to api authentication patterns, which builds directly on these foundations.
API authentication patterns
Three primary patterns for authenticating API clients:
API keys are simple opaque tokens passed in a request header or query string. Suitable for server-to-server integrations where the key can be stored securely in an environment variable or secrets manager. API keys should be at least 256 bits of entropy, rotated on a schedule, and scoped to specific operations. API keys embedded in client-side JavaScript, mobile app binaries, or public repositories are compromised immediately. In 2022, researchers scanning GitHub found over 1 million exposed API keys in public repositories including keys for Twilio, Stripe, SendGrid, and AWS.
OAuth 2.0 bearer tokens provide scoped, time-limited access for user-delegated access scenarios. The resource server validates the token's signature, issuer, audience, and expiry before processing any request (RFC 9068).
Mutual TLS (mTLS) requires both client and server to present certificates during the TLS handshake. mTLS is the strongest method for service-to-service communication in zero-trust architectures because it binds authentication to the transport layer, not a token in the request body.
With an understanding of api authentication patterns in place, the discussion can now turn to rate limiting and api gateway architecture, which builds directly on these foundations.
“APIs that expose sensitive functionality or data must implement appropriate access controls. Object-level access controls must verify that the requesting user has access to the requested object.”
OWASP API Security Top 10 2023, API1: Broken Object Level Authorisation
“API security requires a defence-in-depth approach. Authentication, object-level authorisation, rate limiting, input validation, and logging must all be applied consistently across every endpoint. No single control is sufficient if others are absent.”
NIST SP 800-204: Security Strategies for Microservices-based Application Systems, Section 3.2 (2019)
Rate limiting and API gateway architecture
Rate limits restrict how many requests a client can make within a defined time window, protecting against credential stuffing, scraping, denial of service via API exhaustion, and abuse of computationally expensive endpoints. Rate limits should be applied at multiple levels: per IP address, per API key or access token, per user, and per endpoint. The standard HTTP response when a rate limit is exceeded is 429 Too Many Requests with a Retry-After header.
An API gateway sits between clients and backend services as a single enforcement point for cross-cutting security concerns. Kong (open source) and AWS API Gateway (managed cloud service) both provide: authentication enforcement (validate JWTs or API keys centrally; backend services receive a trusted identity claim), rate limiting (per-consumer, per-route, or global quotas), request transformation (strip or add headers), routing and versioning (support canary releases), and audit logging (every request with caller identity, endpoint, status code, and latency). Centralising these controls at the gateway reduces the risk of individual backend teams implementing them incorrectly or omitting them entirely.
API endpoints should validate every request against a declared schema before processing. For REST APIs, OpenAPI schema definitions allow automatic request validation at the gateway. For GraphQL, query depth and complexity limits prevent expensive nested queries. Reject any request that fails schema validation with 400 Bad Request, returning a generic message and logging the full detail server-side.
Common misconception
“Rate limiting on the authentication endpoint is sufficient protection for an API.”
In the T-Mobile 2023 case, the attacker queried 37 million records over several weeks without triggering any automated throttling or alert on the data retrieval endpoint. Rate limiting must be applied to every data endpoint, not just authentication. Combined with anomaly detection on access patterns such as volume spikes and sequential ID access, it would have detected the exfiltration far earlier.
Common misconception
“An API protected by a WAF (Web Application Firewall) does not need application-level input validation.”
WAFs operate at the network layer and apply generic rules against known attack signatures. They cannot enforce business-logic constraints: a WAF cannot determine whether an order ID in a request belongs to the authenticated user, whether a requested quantity exceeds business limits, or whether a combination of valid parameters constitutes an abuse of a business flow. WAF bypass techniques (encoding variations, HTTP request smuggling, JSON payload obfuscation) are well-documented. Input validation at the application layer is the authoritative control; a WAF is a useful additional layer that reduces the attack surface before requests reach the application.
An e-commerce API endpoint GET /api/orders/{orderId} requires a valid bearer token but returns any order's data regardless of which user the token belongs to. A tester iterates order IDs 1 to 50,000 and retrieves all customer orders. Which OWASP API Security category is this?
A fintech API returns a full user profile including internal fields like internalCreditScore and fraudRiskFlag when a mobile app calls GET /api/me. The app only displays name, email, and accountNumber. A researcher captures the API response and finds the sensitive internal fields. Which OWASP API Security category applies?
A developer builds a GraphQL API for a social media platform. A security researcher reports that the following query returns the private direct messages of any user by querying deeply nested relationships: { user(id: 1) { friends { messages { content } } } }. The query executes in 45 seconds and returns 50,000 records. Which two OWASP API Security categories apply, and what controls address both?
An API gateway receives 500 requests per second from a single API key. The key belongs to a legitimate enterprise customer whose contract allows 100 requests per second. What should the gateway do?
Key takeaways
- BOLA (API1) is the most prevalent API vulnerability: authenticate callers, then authorise access to each object by verifying the caller's relationship to the object identifier.
- API keys suit simple server-to-server integrations; OAuth 2.0 bearer tokens suit user-delegated access; mTLS suits zero-trust service-to-service communication.
- Rate limiting must be applied per endpoint and per identity, not just per IP. Data retrieval endpoints are as important to throttle as authentication endpoints.
- Schema validation at the gateway layer (via OpenAPI definitions) rejects malformed requests before they reach backend services.
- An API gateway centralises authentication enforcement, rate limiting, routing, and audit logging, reducing the risk of inconsistent implementation across individual services.
You can now secure APIs against BOLA, authentication bypass, and abuse. But how do you verify that security controls actually work before code reaches production? What verification gates should exist in a release pipeline? Module 14 covers verification and release gates.
Standards and sources cited in this module
OWASP API Security Top 10 2023
Primary API vulnerability classification reference covering API1 through API10.
NIST SP 800-204A: Security Strategies for Microservices
API gateway and zero-trust API architecture guidance for microservices-based applications.
RFC 7235: Hypertext Transfer Protocol Authentication
HTTP authentication scheme standards and challenge framework.
RFC 9068: JWT Profile for OAuth 2.0 Access Tokens
Bearer token validation requirements: iss, aud, exp, nbf claim validation.
T-Mobile SEC Disclosure, January 2023
Real-world BOLA case study: 37 million records accessed via an unauthenticated API endpoint.