Proxy Module Validation Pattern
Estimated Reading Time: 4 minutes
Security is a top priority when building applications. You don't want to leave data susceptible to interception or manipulation. This is even more true when creating an application for anonymous end-user input. And, it's essential for modules that send sensitive end-user data.
While server-side validation protects your application, it still leaves your application vulnerable. If someone really wants to manipulate your application, they still might be able to. End-users might guess component property names and values. If bad actors guess the names or values correctly, they can send unintended data through your API (application programming interface) calls. An example of this kind of attack is overwriting server-side variables. This is where the Proxy Validation Pattern comes in.
TIP You'll use the Proxy Validation Pattern with the API Architecture Validation Pattern to create an extra layer of security. This article focuses on the Proxy Validation Pattern. To learn more about the API Architecture Validation Pattern, search for Server-side Validation in our In-Product Help.
What You'll Learn
In this article, you'll learn:
A Proxy Validation Pattern involves a Proxy Module that acts as a gateway between end-user input and an internal API Module. You'll use the pattern to validate your end-user's input data on the server. The pattern takes an end-user's input on a module and switches it to the server-side. Bad actors can change parameter values if they identify component property names. On the server, your application's actions don't show to the end-user in the underlying code. By switching to server-side, only intended values from the correct components get through.
For example, say you have a module that collects an end-user's name, address, phone number, and email address. You then want to validate the data and create a submission for storage via an API call. A Proxy Validation Pattern does this outside of your client browser on a Proxy Module. As a result, your API call stores the data values you intended, as bad actors can't manipulate it.
While the Proxy Validation Pattern does give extra security, it comes with drawbacks. You need to weigh these drawbacks against your application's security needs. When you create the Proxy Validation Pattern, you must maintain an extra module. Maintaining another module means keeping it up to date. As you add new components to your modules, you need to update your Proxy Module to keep things secure.
Another potential drawback of the Proxy Validation Pattern is your application's performance. For example, it takes approximately 100 milliseconds to call from the back-end to your module. Creating unnecessary proxy layers or adding extra API calls between modules can slow your application down.
Though it might slow your application, it's important to validate end-user input wherever possible. Ensure you add a Proxy Validation Pattern to the following:
Publicly available modules that allow anonymous users to create or update data.
Mission-critical operations that create or update sensitive data. For example, PII or monetary values.
Despite the Proxy Validation Pattern having drawbacks, the security it offers is essential. For example, say your application receives sensitive, anonymous end-user input. The minor performance drawbacks are worth using the Proxy Validation Pattern.
To validate your end-user's input before it's sent to the API module, set up the Proxy Validation Pattern.
The Proxy Validation Pattern contains the following modules:
This is the end-user-facing part of your application. This is the module your end-user interacts with. For example, they might use this module to fill out an application or upload files.
This module switches your application from the end-user-facing application to the server-side. Think of this as a curtain between your end-user and your application’s inner-workings. Use this module to only send in the allowed inputs for validation.
This module acts as the command center of the server-side validation process. The API Module connects or initiates each action. If the validation doesn't meet your criteria, the API Module sends the error message to the end-user on the Express Module. If the validation meets your criteria, this module proceeds with the API call.
To set up the Proxy Validation Pattern, start with an Express Module to gather end-user input. Then, your Express Module transfers the end-user's input data to the Proxy Module using an API call. Your Proxy Module contains a Plug-In component that executes the API Module. Your Proxy Module's Plug-In only allows the Property IDs included in the Inputs table through to the API Module.
When used with the API Architecture Validation Pattern, the API Module validates the end-user's input in a separate module. After validation, your API Module proceeds with the API call as long as the data meets the validation requirements. The response of your API Module gets sent to your Proxy Module. Then, the Proxy Module sends that response back to your Express Module for the end-user to see. If the data entered doesn't meet the validation requirements, then your end-user receives an error message.
Here's a look at the Proxy Validation Pattern in action: