A developer configures their reverse proxy to cache all HTTP 200 responses with Cache-Control: max-age=3600. The site has a 'My Account' page that displays each user's personal order history and payment methods. What serious problem will this configuration cause?
AThe cache will fill up quickly because account pages are large, degrading performance for other resources
BThe first user's account page will be cached and served to subsequent users requesting that URL, exposing private data
CThe origin server will stop receiving requests and become unavailable when its idle timeout expires
DCache-Control: max-age only works for static assets; it is silently ignored for dynamic pages
Caching personalized content is a critical misconfiguration. When user A requests '/my-account', the proxy caches the response. When user B requests the same URL, the proxy serves the cached version — user A's account page — to user B. This exposes private data and is a serious security vulnerability. Authenticated and personalized responses must be excluded from caching, typically by ensuring responses include headers like `Cache-Control: private, no-store` or `Set-Cookie`, which tell the proxy not to cache them.
Question 2 Multiple Choice
What distinguishes a reverse proxy from a forward proxy?
AA reverse proxy uses HTTPS while a forward proxy uses HTTP
BA reverse proxy operates at layer 4 while a forward proxy operates at layer 7
CA forward proxy acts on behalf of clients (hiding their identity from servers); a reverse proxy acts on behalf of servers (hiding server details from clients)
DA reverse proxy can only cache static files; a forward proxy caches all request types
The 'reverse' in reverse proxy refers to whose side it represents. A forward proxy sits in front of clients: clients configure it explicitly and use it to make requests on their behalf — the server sees the proxy's IP, not the client's. A reverse proxy sits in front of servers: clients connect to it thinking it is the server, unaware of the backend architecture. This distinction matters for understanding security models, trust relationships, and what information each type of proxy hides.
Question 3 True / False
A reverse proxy and a forward proxy perform the same underlying function — the distinction is mainly about physical placement (client side vs. server side), not about whose interests they serve.
TTrue
FFalse
Answer: False
False. The distinction is not merely physical placement — it is about representation and trust. A forward proxy represents clients: it makes requests on their behalf, potentially hiding client identity or caching content for the client network. A reverse proxy represents servers: it intercepts requests before they reach the backend, handles caching and load balancing for the server's benefit, and hides the server architecture from clients. The different roles lead to fundamentally different configurations, security models, and use cases.
Question 4 True / False
A reverse proxy can improve performance for requests that cannot be cached — such as API calls with unique parameters — by terminating TLS, compressing responses, and rate-limiting, even when the response itself is not stored.
TTrue
FFalse
Answer: True
True. Caching is only one of several performance and security benefits that reverse proxies provide. TLS termination offloads expensive cryptographic operations from backend servers. Response compression (gzip/Brotli) reduces bandwidth. Rate limiting, access control, and header manipulation apply regardless of cacheability. For non-cacheable requests, the proxy still reduces latency (TLS termination closer to the client) and protects backends from overload (rate limiting, DDoS mitigation) — the full value of a reverse proxy is not captured by caching alone.
Question 5 Short Answer
Why must cached content in a reverse proxy be carefully controlled, and what categories of responses should generally never be cached?
Think about your answer, then reveal below.
Model answer: Cached responses are served to all clients requesting that resource, so caching content that differs per user or per session is a security and correctness risk. Categories that must not be cached: (1) authenticated or personalized content (account pages, dashboards) — would be served to wrong users; (2) responses to POST/PUT/DELETE requests — non-idempotent, so replaying them would be incorrect; (3) responses with Set-Cookie headers — would set the wrong session for other users; (4) responses with Cache-Control: private or no-store — the server has explicitly forbidden caching.
The core principle is that a cached response will be returned to any client making the same request, so the response must be identical and safe for all of them. Getting this wrong ranges from serving stale data (minor) to exposing one user's private data to another (severe security breach). HTTP cache headers (Cache-Control, ETag, Vary) exist specifically to communicate cacheability rules from the origin server to the proxy, and a reverse proxy must respect them — or configure explicit rules that achieve the same effect.