Reverse Proxy Pattern

From The Secure Arc Wiki

Jump to: navigation, search


Design Pattern

Pattern Name and Classification

Reverse Proxy Pattern


The Reverse Proxy provides a single point of entry, (typically via HTTP), to all of the web, application and other servers making up a system. From a Minimise Attack Surface perspective alone, this is a huge win from a security perspective for an application. This requires that any bugs, misconfigurations or other vulnerabilities that may exist in the servers and applications making up a system must be attacked through the Reverse Proxy, which can limit an attacker to attacks over HTTP.

A Reverse Proxy is typically deployed in a DeMilitarized Zone (DMZ), which supports the Compartmentalise and Defence in Depth principles. The same kind of bugs, misconfigurations and vulnerabilities in the servers that the Reverse Proxy is protecting can also appear in the Reverse Proxy itself. By placing a firewall between the internet and the Reverse Proxy and the protected servers, any compromise of the Reverse Proxy itself can be relatively contained.

Finally, building a custom security solution should only ever be a last resort, especially in very large, high risk systems. Existing security solutions have been out in the wild for many years and are supported by big corporations spending millions of dollars to harden them against many types of attacks that most people wouldn't even think of when starting something from scratch. There are both commercial and open source security solutions available, such as those from Sun (and their Open Source equivalent) and IBM.

Any thoughts that an individual or team of developers could do better not only opens up a system to the same security problems that the big corporations have probably solved in the first few years of their products being on the market, it also means that there is no guarantee that all of the systems within an organisation will be interoperable from a security perspective. This will limit the ability to support single sign-on as well as back end integration.

In short, if you can decouple security from the application development you should. A Reverse Proxy takes the responsibility of authentication completely out of the applications domain and all applications can share the same authentication system. In code, developers need only ask the application container (in a J2EE context) who the user is rather than determine when to authenticate them, how to authenticate them and how to maintain the integrity of a validated credential.

Reusing a single authentication mechanism across applications is great, reusing an off the shelf one is ideal.

Motivation (Forces)


  • Where each impact rating for the Information Assets is sufficiently high and warrant a significant investment in any or all of the security principles listed above
  • Where a large number of in-house and related or co-deployed web or application servers require single sign-on and all reside under the same domain name


At its highest level, the participants are:

  • The End Users
  • The Inbound Firewall
  • The Reverse Proxy
  • The Outbound Firewall
  • The protected Web and/or Application Servers

Not included are the systems the Reverse Proxy will interact with to perform the actual authentication of the user or the user repository this and the Web and/or Application Servers used to determine the entitlements of the user.


The collaboration diagram is made up of the Participants described above. Similarly, it doesn't include all nodes in the process and some details are left out for simplicity and clarity.

  1. A request is initiated from the End User, typically from a Web Browser over HTTP on port 80 or 443
  2. The Inbound FIrewall intercepts and inspects the incoming request, ensures that it has originated from the internet, that it is an HTTP request and that the port requested is either 80 or 443 and that the target is the Reverse Proxy
  3. Assuming all of the validation checks are passed, the Inbound Firewall allows the request to propagate through to the Reverse Proxy
  4. The Reverse Proxy looks at the requested URL and checks its ACL to determine whether authorisation is required.
    1. If authorisation is required for the requested URL, the Reverse Proxy checks whether the End User is already authenticated
    2. If the End User is not authenticated, the End User is prompted to authenticate and the submitted credentials are validated
    3. If authentication is successful, the Reverse Proxy will perform an authorisation check to determine if the End User is allowed to access the requested URL
  5. If the End User is authorised to access the requested URL, the Reverse Proxy proxies the request through to the target Web or Application Server
  6. The Outbound Firewall intercepts and inspects the incoming request, ensures that it has originated from the Reverse Proxy, that it is an HTTP request and that the port requested is either 80 or 443 and that the target is one of the Web or Application Servers
  7. Assuming all of the validation checks are passed, the Outbound Firewall allows the request to propagate through to the Web or Application Server
  8. The Web or Application Server validates that the request was initiated by the Reverse Proxy, either via an embedded credential authenticating the Reverse Proxy itself, a mutually authenticated SSL connection between the Reverse Proxy and the Web or Application Server or by validating a signed End User credential embedded within the request.
    1. Once trust of the request original is established, the Web or Application Server takes the End User credentials provided and translates them into a Web or Application Server specific credential
  9. The Web or Application Server can then perform standard J2EE authorisation checks, as can the Application itself, based on the propagated End User credential established by the Reverse Proxy


There are a number of constraints and consequences introduced by using this approach. Some quite critical that must be addressed at design time to lock down a system.

Security Principles

The Security Principles identified above are satisfied by employing this pattern for the reasons described in the Intent section.

Domain Name

The most prominent consequence that has an impact on the End User is the single web entry point to all systems that a particular Reverse Proxy is protecting. The implications of this are that all of the web applications will have the same domain name with different base URLs.

Where different domain names are required, a single sign-on solution will be much simpler if they all have the same base domain as that will allow session cookies to be shared across the sub-domains. A Cross Domain single sign on solution is significantly more complex, so if it can be avoided at design time it should be.

Isolated Sessions

Web and Application Servers typically have their own mechanism of tracking what sessions belong to what end users. This is normally achieved by storing a session cookie in the web browser. When authentication is delegated to a Reverse Proxy, the Reverse Proxy will most likely have its own session cookie stored in the End Users browser.

This can result in a critical security vulnerability if not addressed. If the Reverse Proxy session cookie is removed, either due to a log out or because it was deleted directly via the browser utilities, the Web and Application Server session cookies will stay in the browser if it is not closed.

If a second user comes along and reuses the same browser window to access the same site, they will be prompted to authenticate by the Reverse Proxy and be given a new session cookie, but the Web and Application Servers will see the previous users cookies still present in the browser and hand that users session to the new user, along with all of their data and entitlements.

This is particular issue is detailed in the Session Validation Pattern


As mentioned above, there are both commercial and open source Reverse Proxy solutions available, such as those from Sun (and their Open Source equivalent) and IBM.

Related Patterns

This is a sub-pattern of the abstract Authentication Pattern and an alternative to the Embedded Authentication Pattern.

One of the consequences of using this pattern is the need to apply the Session Validation Pattern.

The Controlled Zone where the Reverse Proxy is logically deployed is detailed in the Logical Security Zones Pattern.


Personal tools