Confused Deputy Attacks: How CDN Proxies Prevent Privilege Escalation

Every CDN edge server, reverse proxy, and API gateway holds a privileged position in the request pipeline. These intermediaries have network access to backend services, database credentials, service account tokens, and administrative APIs that external clients cannot reach directly. A confused deputy attack exploits this privileged position by tricking the intermediary into using its own authority on behalf of an attacker. The proxy becomes the unwitting accomplice — the "confused deputy" — carrying out actions the attacker could never perform directly. For engineers building CDN infrastructure, understanding confused deputy patterns is essential because every proxy in the request chain is a potential deputy that an attacker can attempt to confuse.

What Exactly Is a Confused Deputy and Why Are CDN Proxies Vulnerable?

The confused deputy problem, first described by Norm Hardy in 1988, occurs when a program with legitimate authority is tricked into misusing that authority by a less-privileged entity. In CDN infrastructure, the deputies are the edge servers, load balancers, API gateways, and edge workers that sit between external clients and internal services. Their privilege comes from their network position (access to internal networks), their credentials (service account tokens for backend APIs), and their configuration (routing rules, rewrite logic, caching policies).

CDN proxies are particularly vulnerable to confused deputy attacks for several reasons. First, they process untrusted input (client requests) and make privileged operations (backend calls) in a single execution context. Second, they often hold broad permissions — an edge server might have credentials to call any backend microservice, even though any individual request should only access one specific service. Third, the speed-focused design philosophy of edge computing sometimes deprioritizes input validation in favor of low-latency forwarding.

The attack manifests differently depending on the proxy's role. A CDN edge function that constructs backend URLs from request headers can be redirected to internal metadata endpoints. An API gateway that forwards authentication tokens without audience validation can be used to access services the token was never intended for. A WAF that makes logging calls based on request content can be exploited to write arbitrary data to audit systems.

How Do Token Forwarding Attacks Create Confused Deputies?

The most common confused deputy pattern in CDN architecture involves improper token forwarding. An edge server receives a request with an OAuth 2.0 access token, validates the token's signature and expiration, and forwards the request (including the token) to a backend service. The vulnerability arises when the edge server does not verify that the token's intended audience matches the backend service being called.

Consider a CDN edge server that routes requests to different microservices based on URL path. A request to /api/orders routes to the orders service, and /api/admin routes to the admin service. If the edge server accepts any valid token and forwards it to whichever service the URL path indicates, an attacker with a token scoped for the orders service can change the URL path to /api/admin. The edge server validates the token (it has a valid signature), forwards it to the admin service, and the admin service — if it trusts the edge server's network position and does not re-validate the audience — processes the request with the orders-service token's identity.

The fix is strict audience (aud) claim validation at every service boundary. The edge server must verify that the token's aud claim matches the service the request is being routed to. If the token was issued for orders-api and the request is routed to admin-api, the edge rejects the request with a 403 before it ever reaches the admin service. When the edge server needs to call a downstream service on behalf of the user, it performs token exchange to obtain a new token with the correct audience for that specific service.

How Does SSRF Exploit CDN Edge Servers as Confused Deputies?

Server-Side Request Forgery (SSRF) is the most operationally dangerous confused deputy pattern in CDN infrastructure. SSRF occurs when an edge server makes HTTP requests to destinations controlled by attacker input. The edge server's network position — inside the cloud VPC, with access to internal services, metadata APIs, and private subnets — becomes the attack surface. The attacker cannot reach these internal services directly, but by controlling where the edge server sends requests, they gain the edge server's network-level access.

In CDN deployments, SSRF commonly manifests in several patterns. Image optimization services that fetch images from user-provided URLs can be redirected to cloud metadata endpoints (http://169.254.169.254/latest/meta-data/) to steal instance credentials. Webhook delivery systems that POST to user-configured URLs can be pointed at internal admin APIs. Edge functions that proxy requests based on user-controllable headers (like X-Forwarded-Host) can be redirected to internal services.

Prevention requires a layered approach. Network-level controls (egress firewalls, security groups) should prevent edge servers from connecting to metadata endpoints and private IP ranges. Application-level controls should validate and sanitize all URLs constructed from user input, resolving DNS before connecting to verify the destination IP is not in a private range. URL allowlisting restricts edge server fetches to known-good domains. For CDN edge workers, the platform's origin protection configuration should restrict which origins the worker can contact, with separate credentials for each origin rather than a single broadly-scoped service account.

What Are Scope Confusion Attacks at the API Gateway Level?

Scope confusion is a confused deputy variant where the API gateway applies the wrong authorization context to a request. This happens when the gateway maps OAuth scopes to internal permissions incorrectly, or when scope semantics differ between the authorization server and the resource server.

Consider an API gateway that receives a token with scope read:documents and routes the request to a document service. The document service interprets read:documents as permission to read all documents in all tenants. But the authorization server issued the token intending read:documents to mean reading only the authenticated user's documents. The gateway, acting as the deputy, faithfully forwards the token with its scope, and the document service grants broader access than intended because the scope semantics are misaligned.

Fixing scope confusion requires explicit scope-to-permission mapping at the gateway layer. Rather than forwarding raw OAuth scopes to backend services, the API gateway should translate scopes into concrete permission assertions. The scope read:documents combined with the sub claim user-4521 should produce a permission context of "read documents owned by user-4521" that is enforced at the gateway, not delegated to the backend service for interpretation. This centralized scope resolution ensures all services in the CDN architecture apply consistent authorization semantics.

How Do Request Context Attacks Exploit Edge Worker Privileges?

Edge workers that construct backend requests based on client request content are vulnerable to request context attacks. The worker uses its own service credentials for backend calls but takes targeting information (URL paths, query parameters, headers) from the client request. An attacker crafts requests that cause the worker to make privileged backend calls the attacker could not make directly.

A typical example: an edge worker handles GET /api/users/{id}/profile by extracting the user ID from the path and calling backend.internal/users/{id} with its service token. If the worker does not validate that the authenticated user matches the requested ID, any user can request any other user's profile through the worker's privileged backend access. The edge worker is the confused deputy — authorized to call the users backend, but confused about which user's data it should access.

The architectural fix is implementing the principle of least authority at the request level. The edge worker should not have a single service token that grants access to all user data. Instead, it should perform token exchange to obtain a token scoped to the specific user and resource being accessed. The exchanged token carries the user's identity in the sub claim and the worker's identity in the act claim, and the backend service uses the sub claim (not the worker's identity) for authorization decisions.

How Does Header Injection Create Confused Deputy Scenarios?

CDN edge servers frequently propagate or set HTTP headers that backend services trust for authorization decisions. The X-Forwarded-For header carries the original client IP. The X-Real-User or X-Authenticated-User header carries the authenticated identity. Custom headers carry tenant IDs, trace contexts, and feature flags. If an attacker can inject these headers in their request and the edge server does not strip or overwrite them, the backend service accepts attacker-controlled identity and context information as if it came from the trusted edge layer.

The most dangerous pattern is identity header injection. If a backend service trusts X-Authenticated-User: [email protected] when it comes from the CDN edge's internal IP, and the edge server passes through this header from the client request without overwriting it, the attacker achieves identity spoofing through the proxy. The CDN edge server is the confused deputy: it has the trusted network position that makes the backend accept the header, and it unknowingly carries the attacker's forged identity claim.

Prevention requires the edge server to always overwrite (not append to) all security-sensitive headers. Headers like X-Forwarded-For, X-Real-IP, and any authentication identity headers must be set by the edge server based on its own verified information, completely replacing any values from the client request. The security header configuration should include an explicit allowlist of headers that are permitted to pass through from client to backend, with everything else stripped. Backend services should reject requests that lack the expected identity headers (indicating they bypassed the edge layer) rather than assuming anonymous access.

What Architectural Patterns Prevent Confused Deputy Attacks at Scale?

Preventing confused deputy attacks across a distributed CDN requires architectural patterns that go beyond point fixes. The foundational principle is capability-based security: rather than giving the deputy broad permissions and trusting it to use them correctly, give the deputy only the specific capability needed for each request.

The first pattern is per-request credential scoping. Instead of edge servers holding long-lived service tokens with broad access, implement token exchange to create request-scoped tokens that carry the user's identity, target only the specific backend service needed, and expire within minutes. A stolen or misused request-scoped token has minimal blast radius compared to a compromised service account token.

The second pattern is request signing at the edge. The edge server signs each backend request with its own key, including a hash of the request body, the target URL, and the authenticated user identity. Backend services verify this signature, ensuring the request was constructed by a legitimate edge server and has not been tampered with. This prevents attackers from crafting requests that look like they came from the edge layer without actually passing through zero-trust verification.

The third pattern is defense-in-depth authorization. Every service in the chain — edge server, API gateway, backend service — must independently verify authorization, not rely on upstream verification. The edge server validates the client token's audience and scopes. The API gateway enforces rate limits and scope-to-endpoint mapping. The backend service checks that the token's sub claim is authorized for the specific resource being accessed. No single layer's confusion can grant unauthorized access because the next layer independently validates.

The fourth pattern is immutable request context. Once the edge server constructs the authorization context for a request (authenticated user, requested resource, permitted operations), that context should be serialized into a signed, tamper-proof format (such as a JWT request context token) and attached to the internal request. Backend services validate this context token rather than deriving authorization from raw request attributes that could be manipulated by intermediate proxies or load balancers.

Confused deputy attacks exploit the gap between authentication ("who is calling?") and authorization ("should this call happen for this request?"). CDN proxies that verify identity but not intent become powerful attack amplifiers, granting attacker-crafted requests the proxy's own network access, credentials, and trusted position. Closing this gap requires audience validation, request-scoped credentials, header sanitization, and defense-in-depth authorization at every layer of the CDN architecture. The goal is not to eliminate proxy privileges — proxies need privileges to function — but to ensure those privileges are exercised only when the request context legitimately warrants them, eliminating the confusion that turns a trusted deputy into an attacker's accomplice.