> ## Documentation Index
> Fetch the complete documentation index at: https://docs.apinizer.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Content Filter

> You can block or clean harmful or sensitive data from request contents with regex-based rules. You can ensure security and data protection by filtering request and response messages

<Tip>
  This document explains the detailed usage of a specific policy. If you are using Apinizer policies for the first time or want to learn the general working principles of policies, we recommend reading the [What is Policy?](/en/concepts/core-concepts/what-is-policy) page first.
</Tip>

## Overview

### What is its Purpose?

* Prevents malicious expressions from reaching your system by scanning header, parameter, and body contents of incoming requests in `API Proxy` calls.
* Ensures anonymization or complete removal of sensitive or personal data before being transmitted to backend systems.
* Detects policy-violating content in requests for regulatory compliance and makes them centrally manageable.
* Reduces manual errors by creating a consistent security layer with predefined filter rules.

### Working Principle

1. **Request Arrival**: For each HTTP/HTTPS request arriving at the API Gateway, the source IP address of the request is identified.
2. **Policy Check**: If the Content Filter policy is active, the system checks in the following order:
   * Is a Condition defined? If so, is the condition met?
   * Is the policy active (active=true)?
   * Is a Variable being used or is Apinizer default?
3. **Content Inspection Rules**: For each defined filter rule, header, parameter, and body fields are scanned regex-based; for body, target fields can be isolated with optional XPath or JSONPath.
4. **Decision Making**:
   * **Match Found**: If `BLOCK` is selected, request is terminated with 403 response; if `DELETE` is selected, matching value is removed from header, parameter, or body and flow continues.
   * **No Match**: Request is forwarded to the next policy in original format.
5. **Error Handling**: Customizable HTTP status code and error message are returned for requests that do not comply with the policy rule.

## Features and Capabilities

### Basic Features

* **Regex-Based Rule Engine**: Suspicious content in header, parameter, or body is caught with rule expressions and removed from processed fields or blocked.
* **Multiple Application Area Selection**: Supports simultaneous application of the same rule on header, query parameter, and body, providing consistent protection.
* **Content Path Targeting**: In body checks, specific nodes/fields can be selected with XPath or JSONPath, enabling targeted filtering.
* **Active/Passive Status Control**: Easily change the active or passive status of the policy (active/passive toggle). In passive mode, the policy is not applied but its configuration is preserved.
* **Condition-Based Application**: Determine when the policy will be applied by creating complex conditions with Query Builder (e.g., only for specific endpoints or header values).

### Advanced Features

* **Predefined Rule Library**: Quickly add validated regex expressions to the policy by selecting from the ready filter rules list.
* **Content Transformation Test**: Validate and improve XPath/JSONPath expressions with Test Transformation modal on live data.
* **Rule-Level Action Selection**: Different behaviors can be assigned to different fields by determining `BLOCK` or `DELETE` decision for each rule.
* **Export/Import Feature**: Export policy configuration as a ZIP file. Import to different environments (Development, Test, Production). Version control and backup capability.
* **Policy Group and Proxy Group Support**: Manage multiple policies within Policy Group. Bulk policy assignment to Proxy Groups. Centralized update and deploy operations.
* **Deploy and Versioning**: Deploy policy changes to live environment. See which API Proxies use it (Policy Usage). Proxy Group and Policy Group usage reports.

## Usage Scenarios

| Scenario                          | Status                                                                | Solution (Policy Application)                                             | Expected Behavior / Result                                               |
| --------------------------------- | --------------------------------------------------------------------- | ------------------------------------------------------------------------- | ------------------------------------------------------------------------ |
| SQL Injection Blocking            | Patterns like `union select` can be seen in parameters                | `ruleValue = (?i)union.+select`, `paramActive = true`, `action = BLOCK`   | When rule matches, request is rejected with 403 and backend is protected |
| Credit Card Masking               | Card number is carried in JSON body                                   | JSONPath `$..cardNumber`, regex `\\b\\d{12,19}\\b`, `action = DELETE`     | Card number is removed from body, request continues with remaining data  |
| Malicious Header Cleanup          | Banned IP list exists in `X-Forwarded-For` header                     | `headerActive = true`, regex banned block, `action = DELETE`              | Header is deleted, logged                                                |
| XML Script Blocking               | `<script>` tag is sent in XML request                                 | XPath selects relevant node, regex `<script>` and below, `action = BLOCK` | Request is instantly blocked and custom error message is returned        |
| DLP - Identity Number             | Turkish ID number is shared in request body                           | JSONPath `$..identityNo`, regex `\\b\\d{11}\\b`, `action = DELETE`        | Identity number is removed; cleaned content appears in logs              |
| Bot Trace Removal                 | `trackingId` parameter should not be carried between systems          | Parameter selection, regex `.+`, `action = DELETE`                        | Parameter is completely deleted, backend does not see unnecessary data   |
| Geographically Restricted Message | Sensitive fields should be cleaned in requests from certain geography | Condition with country-based rule, body path selection, `action = DELETE` | Field is removed only in requests meeting the condition                  |

## Configuring Policy Parameters

In this step, users can **create a new policy** or **configure existing policy parameters** to define access rules.

### Creating a New Content Filter Policy

<img src="https://mintcdn.com/apinizer/bgom9mCEH0MbSei2/images/develop/politikalar/content-new.png?fit=max&auto=format&n=bgom9mCEH0MbSei2&q=85&s=76f268cef55c2f7a62abe98ed2183ba9" alt="Content Filter Policy Configuration" width="1000" data-path="images/develop/politikalar/content-new.png" />

#### Configuration Steps

| Step                                           | Description / Operation                                                                                                                                                                                                                                                                                                                                                                                                                                                      |
| ---------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Step 1: Go to Creation Page**                | - Go to **Development → Global Settings → Global Policies → Content Filtering** from the left menu.<br />- Click the **\[+ Create]** button at the top right.                                                                                                                                                                                                                                                                                                                |
| **Step 2: Enter Basic Information**            | **Policy Status:** Shows Active/Passive status. New policies are active by default.<br /><br />**Name (Required):**<br />Example: `Production_ContentFilter`<br />- Enter a unique name, does not start with space.<br />- System automatically checks. Green checkmark: available. Red X: existing name.<br /><br />**Description:**<br />Example: "Cleans sensitive data from incoming requests."<br />- Max. 1000 characters.<br />- Explain the purpose of the policy.   |
| **Step 3: Variable Usage**                     | - In the action button area at the top of the page, you can use the **\[\<> Variable]** button to select dynamic values.<br />- Using context/global variable expressions, you can manage policy parameters with variable-based values instead of fixed values.<br />- This reduces manual update effort when values change and provides operational convenience.<br />- For detailed information, review [Dynamic Variables](/en/concepts/core-concepts/dynamic-variables). |
| **Step 4: Define Filter Rule**                 | - **Rule Name:** Determine a human-readable rule name.<br />- **Rule Expression:** Enter regex expression or select from ready list.<br />- **Apply On:** Mark Header, Parameter, and Body options to determine the rule's scope.                                                                                                                                                                                                                                            |
| **Step 5: Determine Body Content Target**      | - If Body is selected, define the relevant XPath or JSONPath.<br />- Select content type with XML/JSON radio buttons.<br />- Edit the path in Code editor.                                                                                                                                                                                                                                                                                                                   |
| **Step 6: Action and Test Selection**          | - Terminate request with `BLOCK`, clean content with `DELETE`.<br />- Use **\[Choose]** to select ready rule if needed.<br />- Validate XPath/JSONPath expression with **\[Test Data Transformation]**.                                                                                                                                                                                                                                                                      |
| **Step 7: Define Condition (Optional)**        | - Go to **Condition** tab.<br />- Conditions determine when the policy will be active.<br /><br />**Examples:**<br />- Environment-based: `Header = X-Environment, Operator = Equals, Value = production`<br />- API Key-based: `Header = X-API-Key, Starts With = PROD-`<br />- Endpoint-based: `Path = /api/admin/*`<br /><br />If no condition is defined, policy is always active<br /><br />                                                                            |
| **Step 8: Customize Error Message (Optional)** | - Go to **Error Message Customization** tab.<br />- Customize the message to be returned when access is denied.<br /><br />**Default:**<br />`{ "statusCode": 403, "message": "[Default error message]" }`<br /><br />**Custom:**<br />`{ "statusCode": 403, "errorCode": "[CUSTOM_ERROR_CODE]", "message": "[Custom message]" }`                                                                                                                                            |
| **Step 9: Save**                               | - Click the **\[Save]** button at the top right.<br /><br />**Checklist:**<br />- Unique name<br />- Required fields filled<br />- At least one filter rule exists<br /><br />**Result:**<br />- Policy is added to the list.<br />- Can be connected to APIs.<br />- If global policy, automatically applied.                                                                                                                                                               |

For descriptions of **Conditions** and **Error Message Customization** panels, you can review the [Conditions](/en/concepts/core-concepts/what-is-policy#conditions-conditions) and [Error Message Customization](/en/concepts/core-concepts/what-is-policy#error-message-customization-error-message-customization) sections on the [What is Policy?](/en/concepts/core-concepts/what-is-policy) page.

For a complete guide on all layers, priority order and scenario examples of the error message configuration system, see the [Error Message Configuration Guide](/en/concepts/core-concepts/error-message-configuration) page.

## Deleting the Policy

For deletion steps of this policy and operations to be applied when in use, you can refer to the [What is Policy?](/en/concepts/core-concepts/what-is-policy) page's [Deleting the Policy](/en/concepts/core-concepts/what-is-policy#deleting-the-policy) section.

## Exporting/Importing the Policy

For export (Export) steps and available options of this policy, you can refer to the [Exporting/Importing the Policy](/en/concepts/core-concepts/what-is-policy#exportingimporting-the-policy) section on the [What is Policy?](/en/concepts/core-concepts/what-is-policy) page.

## Connecting the Policy to API

For the process of how this policy will be connected to APIs, you can refer to the [Connect Policy to API](/en/develop/api-proxy-configuration/policy-management#adding-policy-to-flow) section on the [Policy Management](/en/develop/api-proxy-configuration/policy-management) page.

## Advanced Features

| Feature                          | Description and Usage Steps                                                                                                                                                       |
| -------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Regex Template Management**    | - Go to rule list in policy editing screen.<br />- Select ready regex with **\[Choose]** link or enter manually.<br />- Test and confirm before saving.                           |
| **XPath/JSONPath Validation**    | - Activate Body option and determine content type.<br />- Define path in Code editor.<br />- Validate that expression returns correct value with **\[Test Data Transformation]**. |
| **Rule-Based Action Separation** | - Determine `BLOCK` or `DELETE` option for each rule.<br />- Customize error message for blocked rules from Error Message tab.<br />- Review logs of rules using Delete option.   |

## Best Practices

### Things to Do and Best Practices

| Category                     | Description / Recommendations                                                                                                                                                                                                                                  |
| ---------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Regex Management**         | **Bad:** Trying to catch all attacks with a single broad regex.<br />**Good:** Defining separate regexes according to attack type.<br />**Best:** Making small additions according to project needs based on ready templates.                                  |
| **Content Path Definitions** | **Bad:** Targeting body completely.<br />**Good:** Determining XPath/JSONPath for critical fields.<br />**Best:** Using both path and regex to provide maximum protection with minimum scope.                                                                  |
| **Action Selection**         | **Bad:** Making every rule `BLOCK` and cutting requests in false positives.<br />**Good:** Selecting `DELETE` for removable fields, `BLOCK` for risky situations.<br />**Best:** Planning log monitoring after Delete and switching to block mode when needed. |
| **Preview and Test**         | **Bad:** Not testing before going to production.<br />**Good:** Trying with test data in development environment.<br />**Best:** Validating with Test Transformation tool and pre-prod traffic shadowing.                                                      |
| **Policy Conditions**        | **Bad:** Applying policy to every request.<br />**Good:** Defining environment or endpoint-based conditions.<br />**Best:** Determining narrow-scope conditions for risky endpoints, light rules for low-risk areas.                                           |

### Security Best Practices

| Security Area               | Description / Warnings                                                                                 |
| --------------------------- | ------------------------------------------------------------------------------------------------------ |
| **DLP Protection**          | Regularly update sensitive data (identity, card, IBAN) regexes and store in Delete mode.               |
| **Header Integrity**        | Filter untrusted values in incoming headers in chain proxies, log after delete.                        |
| **Regex Performance**       | Avoid complex regexes that may lead to ReDoS; use atomic groups if needed.                             |
| **Error Message Content**   | Do not reveal internal structure in messages returned in Block state; use general but traceable codes. |
| **Log Hygiene Maintenance** | Do not log deleted content; prefer anonymized masks.                                                   |

### Things to Avoid

| Category                             | Description / Warnings                                                                                                                 |
| ------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------- |
| **Overly General Regex**             | **Why to avoid:** Causes false positives and stops legitimate traffic.<br />**Alternative:** Use specific attack signatures.           |
| **Not Defining Path**                | **Why to avoid:** Increases risk of deleting entire body.<br />**Alternative:** Target pinpoint field with XPath/JSONPath.             |
| **Unconditional Global Application** | **Why to avoid:** Creates unnecessary load on low-risk endpoints.<br />**Alternative:** Define targeted conditions with Query Builder. |
| **Deploy Without Testing**           | **Why to avoid:** Blockage or data loss occurs in production.<br />**Alternative:** Validate regex/path combination in test tool.      |

### Performance Tips

| Criterion              | Recommendation / Impact                                                                                                                            |
| ---------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Regex Complexity**   | **Recommendation:** Use non-greedy patterns and limited lookaround.<br />**Impact:** Reduces CPU usage, increases throughput.                      |
| **Rule Count**         | **Recommendation:** Group rules according to risk level, clean unnecessary copies.<br />**Impact:** Evaluation time per request decreases.         |
| **Body Processing**    | **Recommendation:** Select sub-contents with path as much as possible.<br />**Impact:** Parse cost decreases in large bodies.                      |
| **Condition Usage**    | **Recommendation:** Exclude situations where policy does not work with conditions.<br />**Impact:** Unnecessary regex executions are prevented.    |
| **Log and Monitoring** | **Recommendation:** Collect deleted fields as numeric metrics, do not log full content.<br />**Impact:** I/O load decreases, privacy is protected. |

## Frequently Asked Questions (FAQ)

| Category      | Question                                               | Answer                                                                                                                        |
| ------------- | ------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------- |
| **General**   | What types of data does Content Filter Policy audit?   | Header, query parameters, and JSON/XML bodies are scanned regex-based. Body can optionally target XPath/JSONPath.             |
| **General**   | Does the policy work differently globally and locally? | Behavior is the same; global policy can be applied to all proxies while local policy works only on the specified `API Proxy`. |
| **Technical** | Which standard is used as regex expression?            | Java regular expression syntax is used; compiled with `Pattern.compile()` and matched with `Matcher.find()`.                  |
| **Technical** | How is DELETE action applied in body?                  | If path is defined, relevant node is deleted; if undefined, body is pulled to empty string and request continues.             |
| **Usage**     | How is error message customized?                       | Status code, message, and error code fields can be edited in Error Message tab; blocked rule name can be used as parameter.   |
| **Usage**     | Where do ready filter rules come from?                 | They are pulled from the global rule library managed in Admin → Predefined Filter Rules and listed in selection dialog.       |