> This page is for Applications Protection.

> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.humansecurity.com/llms.txt.

# Create Code Defender policy rules

**Policy Rules** let you set up security measures to allow or deny specified script actions and to authorize new or modified scripts to meet PCI DSS 4 requirements. Once a rule is active and a new script or action is detected, then Code Defender goes through the following steps:

1. It checks the script action against each policy rule for any matching conditions.
2. If Code Defender **does** find a match:
   1. **Client-side rules:**
   2. The action will be added to **Policies > Allow list** or **Deny list**
   3. Incidents related to this action will not appear in the **Client-side > Dashboard**
   4. Alerts and notifications related to this action will not be sent to configured integrations
   5. **PCI DSS rules:**
      1. The script status will change to Authorized in the **PCI DSS > Inventory**
      2. The script will no longer appear in the **PCI DSS > Dashboard**
      3. New/modified script alerts & notifications will not be sent to configured integrations
3. If there is not a match, then:
   1. For **Client Side rules,** Code Defender will send the action to **Client-side > Dashboard > Unclassified incidents** for your manual review
   2. For **PCI DSS rules**, Code Defender will set the script status to “Unauthorized” in the  **PCI DSS > Dashboard** and **PCI DSS > Inventory** for your manual review
   3. Corresponding alerts and notifications will be triggered to configured integrations in each case

These steps happen **automatically,** meaning that you can customize your policy rules to automate your workflow and reduce the time it takes to address potential threats or incidents.

You can learn how to create policy rules with this article.

## Prerequisites

* To create or make changes to policy rules, you must have at least a **Developer** role.
* Different types of rules may be available depending on product entitlements.

## Create Client-side rules

### Create a block rule

**Block rules** deny script actions based on the conditions you specify. However, this does **not** block the scripts themselves.  Script actions that match a block rule will appear in your **Code Defender > Policies > Deny List.**

To create a block rule:

1. Navigate to **Code Defender > Policies > Policy Rules.**
2. Select **Create new rule,** then select **Block Rule.**
3. Enter a **Rule name** and **Rule description,** then select **Create rule.**
4. In the **Host Domain** field, complete the following:
   1. Select the **in** dropdown to choose an operator, either **in** or **not in.**
   2. Specify one or more **host domains**  you want to deny actions from. You can enter multiple domains or select **All host domains in this application.**
5. In the **Script** field, complete the following:
   1. Select the **in** dropdown to choose an operator, either **in** or **not in.**
   2. Specify one or more **script vendors** or specific scripts you want to deny actions from. You can enter multiple vendors, select **All scripts,** or enter specific script names that may otherwise not appear in the dropdown menu.
6. Remove any **Script Actions** that you do not want to keep for your rule.

> **Note**
>
> You can remove any behaviors you do not need, but you **must have at least one** to finish creating a rule. You can add behaviors you remove back into a rule at any time.
>
> ![](/_fern-img/fea4f862837f04819121513a23eb96748d8e6c12c58dd09c2e3c70c861c3b1fd.webp)

7. For each remaining **Script Action Type** field, complete the following:
   1. Select the **in** dropdown to choose an operator, either **in** or **not in.**
   2. Specify one or more **values.**
8. Select **Save draft.**
9. Navigate to **Client-side Rules > Draft.**
10. On the rule you just created, select **More options > Activate rule.**

![](/_fern-img/ab20828e2c08351a828f5d184884d00e4984586a92bcfe6dada80b64f09ddfe1.webp)

11. Select a **Rule priority**, then select **Activate rule**. See [Active rule priority](/applications/manage-code-defender-policy-rules#active-rule-priority) for more information on how they’re applied.

You’ve created and implemented your new **block rule.**

### Create an allow rule

**Allow rules** allow script actions based on the conditions you specify. Script actions that match an allow rule will appear in your **Code Defender > Policies > Allow List.**

To create an allow rule:

1. Navigate to **Code Defender > Policies > Policy Rules.**
2. Select **Create new rule,** then select **Allow Rule.**
3. Enter a **Rule name** and **Rule description,** then select **Create rule.**
4. In the **Host Domain** field, complete the following:
   1. Select the **in** dropdown to choose an operator, either **in** or **not in.**
   2. Specify one or more **host domains**  you want to allow actions from. You can enter multiple domains or select **All host domains in this application.**
5. In the **Script** field, complete the following:
   1. Select the **in** dropdown to choose an operator, either **in** or **not in.**
   2. Specify one or more **script vendors** or specific scripts you want to allow actions from. You can enter multiple vendors, select **All scripts,** or enter specific script names that may otherwise not appear in the dropdown menu.
6. Remove any **Script Actions** that you do not want to keep for your rule.

> **Note**
>
> You can remove any behaviors you do not need, but you **must have at least one** to finish creating a rule. You can add behaviors you remove back into a rule at any time.
>
> ![](/_fern-img/fea4f862837f04819121513a23eb96748d8e6c12c58dd09c2e3c70c861c3b1fd.webp)

7. For each remaining **Script Action Type** field, complete the following:
   1. Select the **in** dropdown to choose an operator, either **in** or **not in.**
   2. Specify one or more **values.**

> **Note**
>
> We recommend taking advantage of **not in** to exclude the riskiest script actions when auto allowing a vendor or category of scripts.

8. Select **Save draft.**
9. Navigate to **Client-side Rules > Draft.**
10. On the rule you just created, select **More options > Activate rule.**

![](/_fern-img/ab20828e2c08351a828f5d184884d00e4984586a92bcfe6dada80b64f09ddfe1.webp)

11. Select a **Rule priority**, then select **Activate rule**. See [Active rule priority](/applications/manage-code-defender-policy-rules#active-rule-priority) for more information on how they’re applied.

You’ve created and implemented your new **allow rule.**

## Create PCI-DSS rules

### Create an authorize rule

**Authorize rules** automate new or modified script authorization per PCI DSS based on the conditions you specify.  Authorized scripts will be marked **Authorized** in your **Code Defender > PCI DSS > Inventory.**

1. Navigate to **Code Defender > Policies > Policy Rules.**
2. Select **Create new rule,** then select **Authorize Rule.**
3. Enter a **Rule name** and **Rule description,** then select **Create rule.**
4. In the **Host Domain** field, complete the following:
   1. Select the **in** dropdown to choose an operator, either **in** or **not in.**
   2. Specify one or more of your **host domains** to which you want the rule to apply. You can select multiple domains or select **All host domains in this application.**
5. In the **Script** field, complete the following:
   1. Select the **in** dropdown to choose an operator, either **in** or **not in.**
   2. Specify one or more **script vendors** or **script categories** whose scripts you want to auto-authorize. You can select multiple vendors and categories or select **All scripts.**
6. In the **Authorize Script** field, enter an **Authorization note.** This will be logged every time PCI DSS authorizes a script that matches this rule. Authorization notes appear in **PCI DSS > Audit Report** and in each script’s **Authorization History**, which appear when you open a script in **PCI DSS > Dashboard** or **Inventory**.

![](/_fern-img/850b2ba3b7faf92bf3b49df9075fa6a58862cfd7fb94b455bcf7e3ffadba7875.webp)

7. Select **Save draft.**
8. Navigate to **PCI DSS Rules > Draft.**
9. On the rule you just created, select **More options > Activate rule.**

![](/_fern-img/ab20828e2c08351a828f5d184884d00e4984586a92bcfe6dada80b64f09ddfe1.webp)

10. Select a **Rule priority**, then select **Activate rule**. See [Active rule priority](/applications/manage-code-defender-policy-rules#active-rule-priority) for more information on how they’re applied.

You’ve created and implemented your new **authorize rule.**

## Create a custom rule

**Custom rules** are policy rules with more robust options and applicable logic. Unlike the other types of rules, custom rules have the following features:

* You can create **multiple logical sets** of **host domain(s), script vendor(s), and script action(s).** Each set uses its own conditions and can have nested logic. Code Defender will take action on script actions that match the conditions from **all sets.**
* Each set **does** **not** need all the  **host domain(s), script vendor(s),** or **script action(s)** conditions specified. Instead, each set can use only one, any combination of two, or all three conditions.
* You can take any **action.** This means you can **block, allow,** or **authorize**. You can only choose one action per custom rule.

> **Warning**
>
> Custom rules give you the most flexibility for creating rules, but this flexibility can also create **unintended consequences.** We recommend you **do not** create custom rules unless you are very comfortable with working with custom logic.

## Example policy rule

Below is a sample rule and an explanation of its logic. You can reference this if you’re having trouble understanding how policy rule logic works.

![](/_fern-img/a08631b2bc592bf80c974f10451f15a2a6779f8410702c88c20bc52a692d8159.webp)

In this rule, there are three sets of conditions, one of which has nested logic. This rule’s logic dictates that, for a given script:

* If the **host domain** matches **all host domains in this application**, **AND**
* If the **script vendor** is **Google**, **AND**
* If the **script action type** matches **any one** of the following:
  * The action is **Value Access** and the field ID and name match **c_country** or **creditCard, card_number.** Value access options with two values have an element ID and element name, while those with one value only have the element ID and do not have an element name.
  * The action type is **Set Cookie** and the cookie key is **\_pxvid** or **\_utmb**
  * The action type is **Network** and the domain is **b.px-cdn.net**
* **THEN** Client-side will **block** the specific detected action being evaluated

The **action** is straightforward: if a script matches the listed conditions, then according to this rule, Client-side will **Block** that script’s action.

The **conditions** logic can be more complicated. Let’s start with the first two, which are easier:

* The **host domain** condition tells Client-side to match only actions detected on the listed host domains. In this case, this is **all** host domains associated with the application.
* **AND** the **script** condition tells Client-side to look for scripts who themselves match any of the listed scripts or the listed vendors. In this case, this is **Google.**

**To sum it up:** the first two conditions check that the incoming script matches the given conditions. Based on just these conditions, Client-side will **block** incidents detected on any host domain in your application **AND** taken by any script belonging to Google. Incidents detected on any  host domain in the application but belonging to Facebook, for example, would not be blocked.

Next, let’s look at the **script action type** conditions, which use nested logic with three different types of actions:

* The first action type tells Client-side to look for actions that **are Value Access** actions **and** whose **field ID** or **name** are **c_country** or **creditCard, card_number.**
* The second action type tells Client-side to look for actions that **are Set Cookies** actions **and** whose **cookie key** are **\_pxvid** or **\_utmb**.
* The third action type tells Client-side to look for actions that **are Network** actions **and** whose **domain** is **b.px-cdn.net.**
* The **OR** between these conditions means that Client-side will **block** script actions if the detected script matches **any one** of these conditions.

**To sum it up**: this set of nested conditions tells Client-side to **block** any script actions when the script **accesses values** with **field names** that are **exactly** c_country or creditCard, card_number, **or** when the script **sets cookies** with **cookie keys** that are **exactly** \_pxvid or \_utmb, **or** when the script uses a **network** action with the **exact** **domain** b.px-cdn.net.

To put it all together, note the final **AND()** operator between the **Script** condition and the **Script’s Action Type** nested conditions. This means that Client-side will **block** script actions whose attributes match **all of these conditions at once.**