Firewall quickstart

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:

The firewall holds the rules. It is active from the moment you create it.
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.
The deployment of the workload that serves your application names that firewall, beside the application.
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.

Prerequisites

Console

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.
Access to Azion Console. To sign in, refer to Access Azion Console.

CLI

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.

API

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.
A personal token and curl. To create a token, refer to Manage a personal token.

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.

Console

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.

CLI

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.

API

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>.

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).

Console

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.

CLI

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.

API

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.

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.

Console

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.

CLI

The deployment of a workload is written by azion deploy, from the deployments entry of azion.config.js. To bind the firewall on an existing workload, follow the Console panel.

API

The published Azion API v4 reference has no endpoint for the deployment of a workload. To bind the firewall, follow the Console panel.

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.