Forward proxies versus reverse proxies

01Whose requests does the proxy represent?

An employee's laptop visits an online store. Two intermediaries may be involved, with different owners:

• The company's forward proxy acts for the laptop. The company configures it to control which outside destinations employees may reach.
• The store's reverse proxy acts for the store. The store publishes its address, and the proxy chooses a private API server to handle the incoming request.

A proxy receives traffic and sends it onward. “Forward” and “reverse” describe whose traffic it represents, not mutually exclusive software products. The same software can perform different roles for different connections.

A proxy may cache, inspect or restrict traffic where its protocol and configuration permit. Its presence alone does not make traffic encrypted, anonymous or authorized. The company permitting a connection to the store does not decide whether the shopper may buy a particular item.

02Follow connections and trust boundaries

Follow the laptop's connection to the store:

1. The laptop contacts its configured company proxy. It asks to connect to the store's destination.
2. The company proxy may create an HTTPS tunnel. In that case it relays encrypted application bytes without reading the order body. It can still apply destination and connection rules. If it instead decrypts for inspection, the laptop must trust that setup and the company can read the content.
3. The store's reverse proxy accepts the store's TLS connection. TLS encrypts bytes between its endpoints. Terminating TLS means decrypting them; this proxy can therefore read the request.
4. The reverse proxy opens a new connection to an API worker. Protect and verify that connection separately when its network needs encryption. Encryption on the first connection does not extend automatically to the second.
5. The API checks the user and purchase permission. Routing a request to the API is not authorization for its business operation.

The API may see the reverse proxy's network address rather than the laptop's. A forwarded header can report the original address, but the caller can forge incoming headers. The reverse proxy must replace untrusted values with observed connection information. The API accepts that information only from its configured proxies, not an alternate public route.

One shared company or household address still does not identify one person. Use verified user identity for account permissions.

03Worked example: a company laptop visits a store

Compare the two owners in the same purchase:

Now inject a forged client-address header:

1. An attacker claims to have an internal address.
2. If the store blindly forwards that value, an API might apply a privileged internal policy.
3. The reverse proxy replaces it with information from the actual connection. The API trusts the field only when the request came through the configured proxy chain.
4. Block or equally protect an alternate API route; otherwise the attacker can bypass this checking path.

Finally, label every TLS connection in the drawing. Encrypting both laptop-to-proxy and proxy-to-API traffic still lets a terminating proxy read the content. Decide explicitly which operator is trusted with that readable information.

04Use the proxy for a concrete responsibility

Choose each proxy for a stated responsibility:

• Forward proxy: use it when a client-side organization needs outbound control. Restrict who may use it and which destinations it can reach, so it cannot relay arbitrary traffic for strangers.
• Reverse proxy: use it for a stable public entry point, backend selection, TLS handling or common request controls. Prevent routes that skip mandatory rules.
• Private response caching: include the verified account and any response-changing fields in the cache key, or do not share the response. Never reuse one caller's private response for another merely because their URL matches.
• Availability: run sufficient proxy instances, enforce request deadlines and check whether an order worker can reach the database it needs. Stop sending it orders when that check fails; an open listening port alone does not show it can complete them.
• Configuration changes: release routing rules gradually and keep rollback. Several instances can all fail on the same bad shared rule.

Explain whose policy each proxy enforces, which request bytes it can read and what the API must still check. Those details make “the proxy protects traffic” concrete.