Cybersecurity glossary

What is a Reverse Proxy?

Learn what a reverse proxy is, how it differs from a forward proxy, which features it provides for TLS and routing, and how to harden reverse proxies in production.

Network securityUpdated July 22, 2026
Also known asInbound proxyServer-side proxyApplication reverse proxy

Definition

A reverse proxy is an intermediary that sits in front of one or more origin servers and handles inbound client requests—providing TLS termination, routing, caching, compression, and security controls while making the backends appear as a single service.

Why reverse proxies matter

Application servers should focus on business logic. They should not each reinvent TLS certificates, virtual hosting, compression, bot filtering, and canary routing.

A reverse proxy centralizes those inbound concerns. Clients see one hardened front door; origins stay on private networks answering only the proxy.

Reverse proxy vs forward proxy

AspectReverse proxyForward proxy
Protects / representsServers (origins)Clients
Traffic directionInbound to your appsOutbound from your users/devices
Typical featuresTLS, routing, WAF, load balancingEgress filtering, DLP, anonymity
Who configures itService operatorsEnterprise/client administrators

How a reverse proxy handles a request

1

Client connects to the proxy hostname

DNS points to the proxy or VIP; origins are not directly addressed by users.

2

TLS and policy execute at the front door

Certificates, HTTP versions, redirects, and optional WAF rules apply first.

3

Routing selects an upstream

Host, path, headers, or weights choose which origin pool receives the request.

4

Proxy forwards with trusted headers

X-Forwarded-For/Proto and similar fields preserve client context carefully.

5

Origin responds to the proxy

The application never needs to speak directly to the external client.

6

Proxy returns the response

It may compress, cache, inject headers, or retry idempotent failures per policy.

Common reverse proxy capabilities

TLS termination

Manage certificates once and present a consistent HTTPS posture publicly.

Virtual hosting and path routing

Many apps share one entry IP while Host/path rules split traffic.

Security filtering

WAF, bot scoring, and rate limits reduce noise before it hits app code.

Observability access point

Central access logs and metrics for every public request.

Security risks to control

Origin bypass

If origin ports are public, attackers skip the proxy. Lock down network access.

Request smuggling

Align HTTP parsing with upstreams; reject ambiguous Transfer-Encoding/Length pairs.

Header spoofing

Trust X-Forwarded-* only from the proxy hop; apps must not accept client-spoofed values.

Cache poisoning

Unkeyed headers that affect responses can store the wrong object for other users.

Operational checklist

  • Place reverse proxies as the only public HTTP(S) entry to application origins.
  • Restrict origin security groups/firewalls to proxy egress addresses.
  • Decide TLS termination vs pass-through and whether to re-encrypt upstream.
  • Normalize requests to prevent smuggling between proxy and origin parsers.
  • Configure secure headers (HSTS, CSP where applicable) at the proxy if origins do not.
  • Tune timeouts, body size limits, and WebSocket upgrade support explicitly.
  • Monitor 4xx/5xx, upstream latency, and unexpected direct-to-origin traffic.
  • Review who can change proxy config—treat it as production-critical infrastructure.

The practical takeaway

A reverse proxy is the inbound intermediary in front of your servers: TLS, routing, filtering, and often load distribution in one control point. It is not a forward proxy, and it only helps if origins cannot be reached around it.

Design reverse proxies as security boundaries—parser-safe, network-enforced, header-trust aware—and keep their configuration as carefully reviewed as application code.

Related security terms

Frequently asked questions

What is a reverse proxy in simple terms?

It is a front door for your servers. Users connect to the proxy, and the proxy fetches answers from internal servers—often adding HTTPS, routing, and filtering along the way.

How is it different from a forward proxy?

A forward proxy represents clients going out to the internet. A reverse proxy represents servers receiving inbound traffic from clients.

Is a load balancer a reverse proxy?

Many L7 load balancers are reverse proxies with balancing features. Not every reverse proxy balances across many backends, but the roles overlap heavily.

Why use a reverse proxy instead of exposing apps directly?

Centralize TLS, hide internal topology, add WAF/rate limits, route by hostname/path, and simplify certificate management.

Can reverse proxies cache responses?

Yes. Many do, which reduces origin load—but misconfigured caches can serve private data and must be controlled carefully.

What is request smuggling?

A class of attacks where frontend and backend disagree on HTTP message boundaries, letting attackers sneak requests. Parser alignment is critical.

Do I still need HTTPS behind the proxy?

If the proxy-to-origin path crosses untrusted networks, yes. On a locked private network, some teams use HTTP internally—but understand the trust trade-off.

References

Explore authoritative guidance and frameworks related to reverse proxy.

Explore every security definition

Return to the glossary to search by term, alias, starting letter, or security category.

Browse glossary