Chapter 52 Quiz: API Security Framework¶

B — API1:2023 Broken Object Level Authorization (BOLA) — because every API endpoint that accesses a data object using a user-supplied identifier must perform object-level authorization checks, and unlike role-based page access, these checks must validate that the specific authenticated user owns or is authorized to access the specific object being requested, at the query level

BOLA (also known as IDOR — Insecure Direct Object Reference) is the #1 API vulnerability because APIs expose object identifiers directly in URLs and request bodies (/api/v1/accounts/12345). Traditional web applications often used server-side session state to scope queries, but APIs are stateless — the client explicitly specifies which object it wants. Every endpoint must check: "Does the authenticated user have permission to access object 12345?" This is a per-query, per-object check that cannot be solved with a single middleware or role check. A function-level authorization check ("can this user call the accounts endpoint?") is insufficient — the endpoint must verify ownership or delegation at the object level.

B — The server's JWT library accepts the algorithm specified in the token header, uses the configured RSA public key (which is publicly available) as the HMAC-SHA256 verification key, and validates the forged signature successfully — the mitigation is to explicitly whitelist allowed algorithms in server-side verification configuration and never let the token dictate the algorithm

This is the JWT algorithm confusion attack (CVE-2016-10555 pattern). When a server is configured with an RSA public key for RS256 verification, a vulnerable JWT library will: (1) read "alg": "HS256" from the attacker's token, (2) use the RSA public key as the HMAC secret (since HMAC uses a symmetric key), (3) verify the HMAC signature — which the attacker computed using the same public key. The RSA public key is public by design, so the attacker has everything needed to forge tokens. Fix: configure the server to only accept RS256 (or whichever algorithm is intended), reject all others, and never trust the alg field from the token.

B — The attacker sends an __schema introspection query to enumerate all types, fields, queries, mutations, and subscriptions — maps the complete data model — identifies sensitive fields (SSN, email, payment info) — discovers queries that accept user-controllable arguments (like user(id: ID)) — tests for BOLA by iterating IDs — exfiltrates data through deeply nested queries that follow object relationships

GraphQL introspection is a built-in feature that returns the complete API schema. In production, this gives attackers a complete map of the data model without any fuzzing or guessing. The attack chain: (1) { __schema { types { name fields { name type { name } } } } } reveals all types and fields, (2) the attacker identifies high-value queries like user(id: ID), order(orderId: String), (3) tests for BOLA by changing ID values, (4) uses relationship traversal (user { orders { payments { cardLast4 } } }) to reach sensitive data through authorized entry points. Mitigation: disable introspection in production (introspection: false), disable field suggestions, enforce query depth limits, and implement per-field authorization.

B — A depth attack constructs a single GraphQL query with deeply nested fields that follow circular relationships (e.g., user { friends { friends { friends { ... } } } }), causing exponential backend resolution — a single HTTP request can trigger millions of database queries because traditional rate limiting counts HTTP requests, not GraphQL operation complexity

GraphQL's type system allows circular references: a User type has a friends field that returns [User], each of which has its own friends field. A query nested 10 levels deep on a user with 100 friends per level generates 100^10 resolver calls — from a single HTTP request. Traditional rate limiting (N requests per minute) sees one request and allows it. Mitigations: (1) enforce maximum query depth (typically 7-10 levels), (2) implement query complexity scoring (assign cost to each field, reject queries exceeding a budget), (3) set resolver timeouts, (4) use persisted queries (allowlisted query hashes) to prevent arbitrary queries entirely.

B — An attacker can bypass the rate limit by rotating the X-Forwarded-For header value with different IP addresses on each request — the API trusts the client-supplied header to identify the source IP, which is trivially spoofable when the API is not behind a trusted reverse proxy that strips or overwrites the header

X-Forwarded-For is a standard header used by proxies and load balancers to indicate the original client IP. However, this header can be set by anyone — curl -H "X-Forwarded-For: 192.0.2.1" https://api.example.com/endpoint. If the API uses this header directly for rate limiting without validation, an attacker sends each request with a different X-Forwarded-For value, effectively getting a fresh rate limit bucket for each request. Fix: configure the reverse proxy/load balancer to overwrite X-Forwarded-For with the actual connection IP, or use the rightmost non-private IP in the header chain. Better: use authenticated rate limiting (per API key or per user token) rather than IP-based.

B — Mass assignment occurs when an API endpoint blindly binds all client-supplied JSON properties to the internal data model — an attacker adds extra fields like "role": "admin" or "price": 0.01 to a request body, and the server processes them because it doesn't restrict which properties are accepted — additionalProperties: false in the OpenAPI schema instructs the API gateway or validation middleware to reject any request containing properties not explicitly defined in the schema

Mass assignment (also called auto-binding) is dangerous because APIs typically accept JSON bodies that are deserialized directly into objects. If the User model has a role field and the API doesn't explicitly whitelist allowed fields, a PUT /api/users/me request with {"name": "attacker", "role": "admin"} will update both fields. The additionalProperties: false OpenAPI directive tells schema validation to reject requests containing any field not defined in the schema. This should be enforced at the API gateway layer (Kong, Apigee, AWS API Gateway) before the request reaches application code, creating defense-in-depth.

B — API SSRF is more dangerous because APIs often have programmatic URL parameters (webhook URLs, file import URLs, image processing URLs) that are expected to contain user-supplied URLs — in cloud environments, the instance metadata service (169.254.169.254) is accessible from any workload, allowing an attacker to steal IAM credentials, access tokens, and cloud provider secrets through a single crafted URL parameter

Traditional web applications rarely accept URLs from users. APIs, however, frequently have endpoints that fetch external resources: webhook registration (POST /webhooks {"url": "https://..."}), file import (POST /import {"source_url": "..."}), image processing, PDF generation, etc. Each is a potential SSRF vector. In cloud environments, the metadata service at http://169.254.169.254/latest/meta-data/iam/security-credentials/ returns temporary AWS credentials. An attacker submits {"webhook_url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/my-role"} and the API server fetches the credentials and returns them in the response or stores them where the attacker can retrieve them. Mitigations: use IMDSv2 (requires PUT with TTL), block private IP ranges in URL validation, use allowlists for permitted domains, and enforce egress firewall rules.

B — This is a BOLA/IDOR enumeration attack — the attacker is iterating through sequential user IDs to access other users' data, and the mix of 200 and 403 responses indicates some authorization checks exist but are inconsistent — the correct detection is to alert on a single identity accessing many distinct object IDs in a short timeframe

The telltale signs: (1) sequential object IDs in rapid succession, (2) a single source accessing many different user records, (3) mixed 200/403 responses (indicating partial authorization enforcement — some objects are accessible, others aren't). Detection:

// KQL — BOLA enumeration detection
ApiAccessLog
| where TimeGenerated > ago(5m)
| where UrlPath matches regex @"/api/v\d+/users/\d+"
| extend ObjectId = extract(@"/users/(\d+)", 1, UrlPath)
| summarize DistinctObjects = dcount(ObjectId),
            Requests = count(),
            ResponseCodes = make_set(ResponseCode)
  by SourceIdentity, bin(TimeGenerated, 1m)
| where DistinctObjects > 20

index=api_logs uri_path="/api/v*/users/*"
| rex field=uri_path "/users/(?<object_id>\d+)"
| stats dc(object_id) as distinct_objects count by src_user span=1m
| where distinct_objects > 20

B — gRPC risks include: (1) Protobuf binary encoding is NOT encryption — it can be decoded by anyone with the .proto schema file or through reflection, creating a false sense of security that discourages TLS adoption for internal services; (2) gRPC reflection service exposes the complete API schema (equivalent to GraphQL introspection); (3) bidirectional streaming enables resource exhaustion through long-lived connections; (4) HTTP/2 multiplexing can bypass per-connection rate limits

Teams often assume "binary = secure" and skip TLS for internal gRPC services. Protobuf encoding is deterministic and publicly documented — tools like protoc --decode_raw can decode any Protobuf message without the schema. The gRPC reflection service (grpc.reflection.v1.ServerReflection) is the equivalent of GraphQL introspection — it returns the complete service definition including all RPCs, message types, and field names. Should be disabled in production. Bidirectional streaming (like chat or event feeds) creates long-lived connections that bypass traditional request-based rate limiting and can exhaust server resources if not bounded by timeouts and max message counts.

B — CSWSH works because browsers automatically attach cookies to WebSocket upgrade requests — an attacker's malicious webpage can open a WebSocket connection to the victim's API (new WebSocket("wss://api.example.com/ws")), and the browser sends the victim's session cookies with the upgrade request, establishing an authenticated connection that the attacker controls — unlike CSRF, there is no CORS preflight for WebSocket upgrades and the Same-Origin Policy does not block the connection

The WebSocket handshake starts as an HTTP GET with an Upgrade: websocket header. Browsers treat this as a simple request — no CORS preflight is triggered, and cookies are automatically attached. The attacker's page at evil.example.com opens new WebSocket("wss://api.example.com/ws"), the browser sends the victim's api.example.com cookies, and the server authenticates the connection. The attacker can now send and receive WebSocket messages as the victim. Mitigations: (1) validate the Origin header on the server side during the WebSocket handshake, (2) use token-based authentication (passed in the first message or query parameter) instead of cookies, (3) implement a CSRF-token-like handshake where the client must present a page-specific token to complete the upgrade.

B — The attacker can use path traversal and encoding tricks to bypass the rule: URL encoding (/api/%69nternal/admin), double encoding (/api/%2569nternal/admin), path traversal (/api/v1/../internal/admin), case variation (/api/Internal/admin), or trailing characters (/api/internal/admin/, /api/internal/admin;) — the defense is to normalize the URL path before applying routing rules: decode, resolve traversals, lowercase, strip trailing slashes and semicolons

Path normalization inconsistencies between the API gateway and the backend are a major source of authorization bypass. The gateway applies the block rule against the raw path /api/%69nternal/admin — which doesn't match the rule /api/internal/admin. It forwards the request to the backend, which URL-decodes the path and routes it to the admin endpoint. This is the "parser differential" class of vulnerabilities. Defense: normalize paths at the gateway layer before applying any routing or authorization rules. Use a WAF or API gateway that performs canonical URL normalization. Test with tools like feroxbuster or manual encoding variations.

B — SSRF (API7) is an attack technique where the server makes requests on the attacker's behalf to internal resources, while Security Misconfiguration (API8) provides the conditions that make SSRF exploitable — misconfigured API gateways that allow unrestricted outbound connections, missing egress filtering, debug endpoints left enabled, and overly permissive CORS headers create the environment where SSRF payloads succeed and their results are returned to the attacker

They co-occur because SSRF exploitation typically requires misconfigurations to be impactful: (1) no egress firewall rules (the server can reach internal services and cloud metadata), (2) verbose error messages that return the SSRF response body to the attacker, (3) debug/admin endpoints exposed that accept URL parameters, (4) missing network segmentation between the API tier and sensitive internal services. A well-configured environment with egress filtering, IMDSv2, network segmentation, and minimal error verbosity makes SSRF far less exploitable even if the vulnerability exists in the code.

B — Enforce server-side pagination with strict defaults and maximums: set a default page_size (e.g., 25), enforce a maximum page_size (e.g., 100), use cursor-based pagination (opaque tokens) instead of offset-based to prevent total-count enumeration, never expose a count(*) endpoint that reveals total record counts, and log anomalous pagination patterns (requesting page_size=10000, sequentially requesting all pages)

Unbounded result sets are a data exfiltration vector: GET /api/users?page_size=999999 returns the entire user database in one response. Even with pagination, offset-based pagination (?page=1&size=100) reveals total record count and allows predictable enumeration. Cursor-based pagination uses opaque tokens (?cursor=eyJpZCI6MTAwfQ==) that don't reveal total count or position. Detection: monitor for clients requesting maximum page sizes, sequentially paginating through entire datasets, or accessing pagination endpoints they've never used before. These patterns indicate automated data harvesting.

B — API key sprawl occurs when API keys are embedded in source code, configuration files, CI/CD pipelines, and shared across teams without rotation or scoping — in microservice architectures, each service consumes multiple internal and external APIs, creating a web of credentials where one compromised key can cascade through the entire service mesh, and API10:2023 warns that services often trust consumed APIs without validating their responses, so a compromised upstream service can inject malicious data that downstream services process blindly

In a 50-service microservice mesh, each service might consume 5-10 APIs (internal and external), creating 250-500 credential relationships. If credentials are shared, unrotated, or overly scoped, compromising one service gives access to all APIs it consumes. API10:2023 (Unsafe Consumption) adds another dimension: services that consume third-party APIs often trust the response data without validation. If a consumed API is compromised (or the attacker substitutes a malicious endpoint), the consuming service processes attacker-controlled data — potentially leading to injection, SSRF, or business logic abuse. Mitigate with: secrets management (Vault, AWS Secrets Manager), least-privilege API key scoping, automatic rotation, and input validation on ALL consumed API responses.

B — Layer 1: API Gateway — authentication, rate limiting, schema validation. Layer 2: Service Mesh — mutual TLS, authorization policies, certificate rotation. Layer 3: Application-level — BOLA checks, input validation, output filtering. Layer 4: Runtime protection — anomaly detection, JWT verification, payload inspection. Layer 5: Observability — centralized logs, detection queries, API inventory, shadow API detection. Each layer catches what the previous layer misses.

Defense-in-depth is essential because no single layer catches everything: (1) The API gateway handles authentication and rate limiting but cannot enforce object-level authorization (BOLA) — that requires business logic. (2) The service mesh ensures all internal traffic is encrypted and authenticated but doesn't validate request payloads. (3) Application-level controls enforce business rules but can be bypassed if the service mesh allows direct access. (4) Runtime anomaly detection catches novel attack patterns that static rules miss. (5) Observability enables detection engineering and shadow API discovery. For financial services, add: API versioning lifecycle management, PCI DSS-specific controls for payment APIs, regulatory audit trails, and chaos engineering for API resilience testing.