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

# Configurational Classes

The HUMAN BigIP module allows you to set a number of configurational classes (data groups) to control which routes are processed in different ways.

## Whitelist Routes

Routes added to this class will bypass HUMAN enforcement entirely.

1. On **Local Traffic** > **iRules** > **Data Group List** create a new Data Group.
2. Set the **Name** to *px\_\<APP_ID>\_whitelisted_routes*. Make sure to replace `<APP_ID>` with your HUMAN app id.
3. Set **Type** to *String*.
4. For each route you wish to allow, set the **String** property of *String Record* to the prefix of the route and click **Add**.
5. Click **Finished**.
6. On the iRule, make sure the value of `whitelisted_routes_class` directive is the same as the name you provided in step 2.

## Whitelisted Query Parameters

Query parameters added to this class will be excluded from the URL sent to HUMAN for risk evaluation. This is useful for removing sensitive or dynamic parameters from the evaluation.

1. On **Local Traffic** > **iRules** > **Data Group List** create a new Data Group.
2. Set the **Name** to *px\_\<APP_ID>\_whitelisted_query_params*. Make sure to replace `<APP_ID>` with your HUMAN app id.
3. Set **Type** to *String*.
4. For each URI query parameter you wish to whitelist:
   * Set the **String** property to the query parameter key name
   * Set the **Value** property to a **regex pattern** matching the values to whitelist
   * Click **Add**
5. Click **Finished**.

> **Note**
>
> The **Value** field uses regex matching. For example, to whitelist all values for a parameter, use `.*` as the value.

**Example:** To whitelist the `session_id` parameter with any value:

* String: `session_id`
* Value: `.*`

## Specific Routes

Routes added to this class will be the only routes that HUMAN enforces. All other routes will bypass enforcement.

1. On **Local Traffic** > **iRules** > **Data Group List** create a new Data Group.
2. Set the **Name** to *px\_\<APP_ID>\_specific_routes*. Make sure to replace `<APP_ID>` with your HUMAN app id.
3. Set **Type** to *String*.
4. For each route you wish to enforce, set the **String** property of *String Record* to the prefix of the route and click **Add**.
5. Click **Finished**.
6. On the iRule, make sure the value of `specific_routes_class` directive is the same as the name you provided in step 2.

## Sensitive Routes

Routes added to this class will trigger a server-to-server risk API call regardless of the cookie score. This provides higher security for critical endpoints.

1. On **Local Traffic** > **iRules** > **Data Group List** create a new Data Group.
2. Set the **Name** to *px\_\<APP_ID>\_sensitive_routes*. Make sure to replace `<APP_ID>` with your HUMAN app id.
3. Set **Type** to *String*.
4. For each sensitive route, set the **String** property of *String Record* to the prefix of the route and click **Add**.
5. Click **Finished**.
6. On the iRule, make sure the value of `sensitive_routes_class` directive is the same as the name you provided in step 2.

## Monitor Routes

Routes added to this class will be processed in monitor mode regardless of the global `module_mode` setting. This allows you to enable blocking mode globally while keeping specific routes in monitor mode, or vice versa.

The class supports domain/path based configuration for more granular control.

1. On **Local Traffic** > **iRules** > **Data Group List** create a new Data Group.
2. Set the **Name** to *px\_\<APP_ID>\_monitor_routes*. Make sure to replace `<APP_ID>` with your HUMAN app id.
3. Set **Type** to *String*.
4. For each route you wish to set to monitor mode:
   * Set the **String** property to the domain and path (e.g., `example.com/api`)
   * Click **Add**
5. Click **Finished**.

> **Note**
>
> Monitor routes can be specified with just a path (e.g., `/api/v1`) or with a domain prefix (e.g., `api.example.com/v1`).

## Login Credentials Extraction

This class defines the endpoint where login credentials should be extracted. The credentials are hashed and sent to HUMAN for breach detection.

> **Note**
>
> Before creating this class, ensure Credential Intelligence is enabled in the `pxconfig` data group. See [Credential Intelligence](/applications/bigipf5-configuration-properties#credential-intelligence) for details.

1. On **Local Traffic** > **iRules** > **Data Group List** create a new Data Group.
2. Set the **Name** to match the value configured in `ci_login_credentials_extraction_class` (e.g., `px_login_credentials`).
3. Set **Type** to *String*.
4. Add the following records with their corresponding values:

| String (Key) | Description                                                           | Example Value |
| ------------ | --------------------------------------------------------------------- | ------------- |
| path         | Regex pattern for the login endpoint path (case-insensitive matching) | `/login`      |
| method       | HTTP method for login requests (case-insensitive matching)            | `POST`        |
| sent_through | Where credentials are located: `body`, `header`, or `query-string`    | `body`        |
| user_field   | Field name containing the username                                    | `username`    |
| pass_field   | Field name containing the password                                    | `password`    |

5. Click **Finished**.

> **Note**
>
> Both path and method matching are case-insensitive. The path field supports regular expression patterns.

### Example: JSON Body Login

For a login endpoint at `/api/auth/login` that accepts POST requests with JSON body:

```json
{
  "email": "user@example.com",
  "password": "secretpassword"
}
```

Configure the class with these records:

| String       | Value             |
| ------------ | ----------------- |
| path         | `/api/auth/login` |
| method       | `POST`            |
| sent_through | `body`            |
| user_field   | `email`           |
| pass_field   | `password`        |

### Example: Form POST Login

For a login form that submits to `/login` with form-urlencoded data:

| String       | Value      |
| ------------ | ---------- |
| path         | `/login`   |
| method       | `POST`     |
| sent_through | `body`     |
| user_field   | `username` |
| pass_field   | `password` |

### Supported Content Types for Body Extraction

When `sent_through` is set to `body`, the enforcer supports:

* **application/json** - JSON request bodies
* **application/x-www-form-urlencoded** - Form-encoded request bodies

The enforcer automatically detects the content type based on the `Content-Type` or `Accept` request header.

### Extraction from Headers

When `sent_through` is set to `header`, the `user_field` and `pass_field` values specify the header names:

| String       | Value        |
| ------------ | ------------ |
| path         | `/api/login` |
| method       | `POST`       |
| sent_through | `header`     |
| user_field   | `X-Username` |
| pass_field   | `X-Password` |

### Extraction from Query String

When `sent_through` is set to `query-string`, the `user_field` and `pass_field` values specify the query parameter names:

| String       | Value          |
| ------------ | -------------- |
| path         | `/login`       |
| method       | `GET`          |
| sent_through | `query-string` |
| user_field   | `user`         |
| pass_field   | `pass`         |

This would extract credentials from a URL like `/login?user=john&pass=secret`.