Install the Method and Route Validator integration
Install Method and Route Validator from Azion Marketplace and run it on a firewall to block requests by their URI and HTTP method.
Preview
You install the Method and Route Validator integration from Azion Marketplace and run it on a Firewall, from Azion Console. The function protects your application by blocking requests based on the URI and the method they use. You list the routes your application expects and the methods each route accepts, and the function checks every request against those patterns.
Five objects have to exist before a request is validated: the installed function, a firewall carrying the Functions module, a function instance holding the routes, a Rules Engine rule with the Run Function behavior, and a workload deployment bound to the firewall. Each section below creates one of them.
Prerequisites
- An Azion account. To sign in, refer to How to access Azion Console.
- An application served by a workload, whose deployment you bind to the firewall in the last section.
- The Azion CLI installed and authorized, for the last section.
- Turning on a product or a module can generate usage costs. For more information, refer to Pricing.
Install the integration
The function is installed once per account. To install it:
Access Azion Console > Marketplace.
Enter Method and Route Validator in the Search on Marketplace field, then select the integration’s card. Browsing the cards and the categories reaches the same page.
The card shows Successfully installed! and Latest version installed!, and the function appears in the Function list of the Create Instance drawer.
Create the firewall
The firewall is where the function is instanced and where the rule that runs it lives. To create one:
Access Azion Console > Firewalls, then create a firewall.
In the General section, enter a Name. For example: route-validator-firewall.
In the Modules section, turn on the Functions switch. The switch gives the firewall access to functions.
The firewall shows a Functions Instances tab while the Functions module stays on. To use an existing firewall instead, turn on its Functions module and save it. For every setting on this form, refer to Set a firewall’s main settings.
Create the function instance
The instance holds the routes, their methods, and the action for an invalid request. To create it:
In Firewalls, select your firewall, then select the Functions Instances tab.
A firewall that has no instance shows the same action as Function Instance. The Create Instance drawer opens.
In Name, enter a name. For example: method-route-validator.
In Function, select the Method and Route Validator function. The list holds only the functions that run on a firewall.
In Arguments, the editor is prefilled with the integration’s default arguments in JSON. Enter your routes and values, as the next section describes.
The instance is listed in the Functions Instances tab.
Arguments
Pass the arguments as in this example:
| Property | Type | Required | Description |
|---|---|---|---|
restricted_mode | Boolean | No | Sets whether the function runs in restricted mode. Default value: false. |
action | String | Yes | The action the function takes when it identifies a request as invalid. |
routes | Array | Yes | All the URIs the protected application expects to handle. |
routes.match_type | String | Yes | The type of match the function runs on the path. |
routes.path | String | Yes | The argument the function uses to validate the request URI. |
routes.methods | Array | Yes | The methods a request to the path can use, as an array of strings. |
redirect_to | String | Only when action is redirect | The URL that receives the request when the redirect action runs. Can be a complete request URL or a relative path. |
custom_response_body | String | Only when action is custom_response | The custom response body the function sends when the custom_response action runs. |
custom_response_status | Number | No | The status code of the response the function sends when the custom_response action runs. Default value: 400. |
custom_response_content_type | String | No | The content type of the response the function sends when the custom_response action runs. Default value: plain/text. |
The action argument accepts these values:
| Action | Description |
|---|---|
deny | Closes the request with an HTTP 403 Forbidden response. |
drop | Closes the request without a response to the client. |
redirect | Redirects the request to another location. |
custom_response | Closes the request with a static response. |
The match_type argument accepts these values:
| Match type | Description |
|---|---|
equals | The path must be equal to the path argument. |
contains | The path must contain the path argument. |
regex | The path must match the regular expression in the path argument. |
Request validation
Each time the function runs, it takes these steps:
- It validates the arguments passed to the function. When the arguments are invalid, the function writes a log message and continues the request.
- It checks whether the request matches the patterns of the routes.
- When the request matches, the function runs the blocking action you set. When the request does not match, the function continues the request or blocks it, as you configure it.
Create the rule
The instance validates nothing until a rule runs it. A Rules Engine for Firewall rule selects the requests that reach the instance, through a Run Function behavior. To create the rule:
In Firewalls, select your firewall, then select the Rules Engine tab.
In Name, enter a name. For example: Run Method and Route Validator.
In the Criteria section, select the domains that run the integration. For example: if Host matches yourdomain.com.
In the Behaviors section, select Run Function, then select the instance by the name you gave it.
The firewall runs the instance on every request to the domains in the criterion.
Bind the firewall to the workload
The binding is on the workload’s deployment, so create a deployment that names both the application and the firewall:
The command prints the id of the new deployment:
Requests to the workload’s domain reach the firewall, and the rule runs the Method and Route Validator instance on each one.