DedSec Project

CDN, Reverse Proxy, Cache and Edge Security — DedSec Project

CDN, Reverse Proxy, Cache and Edge Security Modern web applications often have several HTTP-speaking systems before the origin. Learn edge trust, cache keys, normalization, origin…

Modern web applications often have several HTTP-speaking systems before the origin. Learn edge trust, cache keys, normalization, origin protection, signed requests and observability.

Learning objectives

By the end of this module you should be able to:

Deep concepts

1. CDN and reverse-proxy trust boundaries

A CDN or reverse proxy terminates connections and may rewrite routing, identity, cache, and security headers before forwarding to an origin. The origin should authenticate trusted proxy paths and reject client-controlled values that are supposed to be set only by the edge.

2. cache keys and Vary

A cache key determines which requests share a stored response. Security review must include host, path, query, headers, cookies, encoding, authorization state, and Vary behavior so private or attacker-influenced content is not reused for another context.

3. header normalization and forwarding

Edges and origins can disagree about duplicate headers, whitespace, casing, hop-by-hop fields, or forwarding metadata. Define a canonical policy and test it end to end; access-control decisions should not depend on a header that an untrusted client can preserve or inject.

4. origin authentication and shielding

Private origins should accept traffic only from intended edge/shield paths and authenticate that relationship where practical. IP allowlists alone can become brittle; combine network restrictions with TLS identity, signed requests, or equivalent service authentication when supported.

5. signed URLs and cookies

Signed URLs/cookies delegate time- and resource-bounded access to edge content. Bind signatures to the intended path/resource, expiration, audience/context, and key version; avoid broad wildcards that turn a narrow share link into general origin authority.

6. cache poisoning classes

Cache poisoning is a state-integrity problem: an attacker-influenced response becomes associated with a key used by other clients. Defensive testing should use synthetic content and verify key construction, unkeyed inputs, error caching, and purge behavior without affecting public users.

7. edge compute and request mutation

Edge functions can authenticate, redirect, transform headers, or fetch additional data, making them part of the application security boundary. Apply code review, least privilege, secret isolation, versioned deployment, and observability comparable to backend services.

8. purge and incident response

A corrected origin does not remove already cached unsafe content. Incident plans need authenticated purge/invalidation, scope controls, propagation evidence, rollback, and verification from multiple edge locations without exposing customer data.

Authorized lab sequence

Knowledge checks

Answer these without looking at the notes:

Next modules

Recommended related modules: 013, 014, 041, 052, 069, 104, 124. From the main menu, choose Search lessons to find related sections across the full guide.