Firewall quickstart

Create a firewall, add a rule that denies requests to one path, bind the firewall to a workload, and confirm the path answers 403.

Last updated

View as Markdown Agent setup

This guide instructs you through denying your first request with a firewall.

  • Create a firewall for the application you already serve.
  • Add a rule that denies every request to one path.
  • Bind the firewall to the workload that serves your application.
  • Send a request to that path and read the 403 it returns.

Four objects turn a request into a decision, and each one links to the next:

  1. The firewall holds the rules. It is active from the moment you create it.
  2. The rule on that firewall pairs a criterion with a behavior. The criterion selects requests, and the behavior decides what happens to them. In this guide, the criterion selects every path that starts with /deny-test, and the behavior denies the request.
  3. The deployment of the workload that serves your application names that firewall, beside the application.
  4. The request to the workload’s domain meets the rule, and a denied request never reaches your application.

A firewall inspects nothing on its own. Until a workload’s deployment names it, no request reaches its rules.

Web Application Firewall (WAF), Network Shield, and Bot Manager are Products enabled on a firewall. This guide needs none of them, because Deny is built into every firewall. Each Product’s quickstart starts from a firewall bound to a workload, which is what this guide leaves you with.

Select the interface you use. The prerequisites and every stage on this page follow that choice.

Prerequisites

  • An Azion account. To create one, refer to Create an account.
  • A workload that serves an application on its workload domain. For more information, refer to Workloads.
  • The Azion CLI, installed and authorized.
  • The ID of your workload and the ID of the application it serves.
  • A personal token and curl. To create a token, refer to Manage a personal token.
  • The ID of your workload and the ID of the application it serves.

Create the firewall

A new firewall holds no rules, and it starts active. The Deny rule this guide adds needs no Product turned on, so the default settings stay.

To create the firewall with the Azion CLI:

azion create firewall --name "storefront-firewall" --active true

The command prints the ID of the new firewall:

Created Firewall with ID 12352

The firewall is active, with Functions and Network Shield turned on and WAF turned off. Record the ID. The rule and the binding to your workload pass it as --firewall-id.

To create the firewall with the API, send a POST request to the firewalls endpoint. Replace [TOKEN VALUE] with your personal token:

Shell
01curl --request POST \
02 --url https://api.azion.com/v4/workspace/firewalls \
03 --header 'Accept: application/json' \
04 --header 'Authorization: Token [TOKEN VALUE]' \
05 --header 'Content-Type: application/json' \
06 --data '{"name": "storefront-firewall"}'

This excerpt of the response shows the new firewall and the settings it starts with:

JSON
01{
02 "state": "pending",
03 "data": {
04 "id": 12353,
05 "name": "storefront-firewall",
06 "modules": {
07 "ddos_protection": { "enabled": true },
08 "functions": { "enabled": true },
09 "network_protection": { "enabled": true },
10 "waf": { "enabled": false }
11 },
12 "debug": false,
13 "active": true,
14 …
15 "product_version": "2.0",
16 …
17 "version": 0
18 }
19}

The firewall is active, and waf is the one entry in modules that starts turned off. Record the id. The rule and the binding to your workload pass it as <firewall-id>.

To create the firewall in Azion Console:

Open the Firewalls page

Access Azion Console > Secure > Firewalls.

Start a new firewall

Select Firewall. The Create Firewall page opens.

Name the firewall

In the General section, enter a Name. For example: storefront-firewall.

Leave the other sections as they open

A Deny rule needs no switch in Modules. In Status, Active stays turned on.

Select Create

Azion Console shows the message “Your Firewall has been created” and opens the firewall. Its tabs are Main Settings, Functions Instances, and Rules Engine. Functions Instances appears only while Functions is turned on.

Add a rule that denies one path

A Rules Engine for Firewall rule pairs criteria with behaviors. The rule in this stage carries one criterion, a request URI that starts with /deny-test, and one behavior, Deny. Deny refuses the request with 403 Forbidden, and it needs no Product turned on.

The criterion matches every path that begins with /deny-test, so /deny-test/page matches too. For more information, refer to Deny (403 Forbidden).

azion create firewall-rule reads the whole rule from a JSON file. criteria is a list of groups, and the first criterion of a group carries the conditional if. Save this rule as rule.json:

JSON
01{
02 "name": "Deny the test path",
03 "active": true,
04 "criteria": [
05 [
06 {
07 "variable": "${request_uri}",
08 "conditional": "if",
09 "operator": "starts_with",
10 "argument": "/deny-test"
11 }
12 ]
13 ],
14 "behaviors": [
15 { "type": "deny" }
16 ]
17}

Create the rule. Replace <firewall-id> with the ID of your firewall:

azion create firewall-rule --firewall-id <firewall-id> --file rule.json

The command prints the ID of the new rule:

Created Firewall Rule with ID 123460

The rule is active on the firewall.

The request body is the rule itself. criteria is a list of groups, and the first criterion of a group carries the conditional if. Save this rule as rule.json:

JSON
01{
02 "name": "Deny the test path",
03 "active": true,
04 "criteria": [
05 [
06 {
07 "variable": "${request_uri}",
08 "conditional": "if",
09 "operator": "starts_with",
10 "argument": "/deny-test"
11 }
12 ]
13 ],
14 "behaviors": [
15 { "type": "deny" }
16 ]
17}

Send a POST request to the rules of your firewall. Replace <firewall-id> with the ID of your firewall:

Shell
01curl --request POST \
02 --url https://api.azion.com/v4/workspace/firewalls/<firewall-id>/request_rules \
03 --header 'Accept: application/json' \
04 --header 'Authorization: Token [TOKEN VALUE]' \
05 --header 'Content-Type: application/json' \
06 --data @rule.json

This excerpt of the response shows the new rule’s id and its order among the rules of the firewall:

JSON
01{
02 "state": "pending",
03 "data": {
04 "id": 123459,
05 …
06 "behaviors": [{ "type": "deny" }],
07 "description": "",
08 "order": 0
09 }
10}

The API assigns order in creation order, starting at 0. The rule is active on the firewall.

To add the rule in Azion Console:

Open the firewall

Access Azion Console > Secure > Firewalls, and select the firewall you created.

Select the Rules Engine tab
Start a new rule

Select Rule. The Create Rule drawer opens.

Name the rule

In the General section, enter a Name. For example: Deny the test path.

Set the criterion

In the Criteria section, the first criterion opens on Request Uri and starts with. Enter /deny-test as its argument.

Select the Deny behavior

In the Behaviors section, select Deny (403 Forbidden).

Select Save

Azion Console shows the message “Rule successfully created”. The rule appears in the Rules Engine list with the status Active.

Bind the firewall to your workload

A firewall has no domain of its own. The workload carries the domain. Its deployment holds exactly three settings: the application, the firewall, and the custom page. Name the application the workload serves today, and its custom page if it uses one, beside your firewall. Until the deployment names your firewall, the Deny rule matches no request.

To bind the firewall with the Azion CLI, create a deployment that names your firewall and the application the workload serves today. Replace the three IDs:

Shell
01azion create workload-deployment --workload-id <workload-id> \
02 --name storefront-deployment --application-id <application-id> \
03 --firewall-id <firewall-id> --strategy-type default --active true --current true

The command prints the ID of the new deployment:

Created Workload Deployment with ID 123462

--current true makes it the current deployment of the workload, which names your application and your firewall. If the workload uses a custom page, add --custom-page <custom-page-id> to the command.

To bind the firewall with the API, send a POST request to the deployments of your workload. The firewall goes in strategy.attributes.firewall, beside the application the workload serves today. If the workload uses a custom page, name it in custom_page too. Replace the three IDs:

Shell
01curl --request POST \
02 --url https://api.azion.com/v4/workspace/workloads/<workload-id>/deployments \
03 --header 'Accept: application/json' \
04 --header 'Authorization: Token [TOKEN VALUE]' \
05 --header 'Content-Type: application/json' \
06 --data {
07 "name": "storefront-deployment",
08 "current": true,
09 "active": true,
10 "strategy": {
11 "type": "default",
12 "attributes": {
13 "application": <application-id>,
14 "firewall": <firewall-id>
15 }
16 }
17}

The response returns the deployment. Its strategy.attributes holds the application, the firewall, and custom_page, which is null when the workload uses no custom page:

JSON
01{
02 "state": "pending",
03 "data": {
04 "id": 123461,
05 "name": "storefront-deployment",
06 "current": true,
07 "active": true,
08 "strategy": {
09 "type": "default",
10 "attributes": {
11 "application": <application-id>,
12 "firewall": <firewall-id>,
13 "custom_page": null
14 }
15 },
16 "last_editor": "user@example.com",
17 "last_modified": "2026-01-01T12:00:00.000000Z",
18 "created_at": "2026-01-01T12:00:00.000000Z"
19 }
20}

The current deployment of the workload names your application and your firewall.

To bind the firewall in Azion Console:

Open the Workloads page

Access Azion Console > Workloads.

Open your workload

Select the workload that serves your application. Its edit form opens.

Select the firewall

In the Firewall field of Deployment Settings, select the firewall you created. Application and Custom Page keep what the workload serves today.

Select Save

The deployment of the workload names your firewall, beside its application and its custom page.

Confirm that the path answers 403

The check is the same whichever interface built the firewall. Your workload answers on its workload domain, of the form <id>.map.azionedge.net, written in this stage as <your-workload-domain>.

A workload newly bound to a firewall can take several minutes to enforce its first rule, and no duration is guaranteed. While the binding spreads, answers to the same request alternate between the earlier response and the new one. Until then, the path still reaches your application. Send the request again until it answers 403. For more information, refer to Propagation.

Send a request to the denied path:

curl -i https://<your-workload-domain>/deny-test

The firewall refuses it with 403:

Text
01HTTP/2 403
02server: nginx
03date: Thu, 01 Jan 2026 12:00:00 GMT
04content-type: text/html; charset=utf-8
05x-content-type-options: nosniff
06x-azion-request-id: 0123456789abcdef0123456789abcdef
07x-azion-edge-location: <edge-location>
08alt-svc: h3=":443"; ma=86400

The response also carries a long content-security-policy header, omitted from this excerpt. The body is Azion’s default error page, headed Forbidden, and it lists your IP address and the request ID. No header names the firewall or the rule that refused the request.

Requests to every other path do not match the rule, and your application answers them as before. Your firewall denies every request whose path starts with /deny-test.

Next steps

WAF quickstartCreate a WAF rule set, apply it with a Set WAF behavior, and see an injection-shaped request refused.Network Shield quickstartPut your own IP address in a network list and deny that list on one test path.Bot Manager quickstartRun Bot Manager Lite from a Run Function rule and read the score it gives a request.Rules Engine for FirewallEvery criterion, operator, and behavior a firewall rule accepts, with the rule body for the API and the CLI.How Firewall worksThe path a request travels through a firewall, the order its rules run in, and how a change propagates.Firewall limitsThe bounds on rules and function instances per firewall, and the limits each Product adds.