App Firewall

tCell attack sensors recognize malicious patterns of input in various forms. The specific text or bytes that are recognized as malicious are called the payload.

You can use the App Firewall screen to configure what payload data is collected, where it is stored and the specific attack patterns that tCell will detect.

By default, in order to provide the most context about attacks, payload data is sent to the tCell cloud. If needed, it’s also possible to log this data locally.

Identify sensitive fields before using tCell

Before using tCell, it’s important to identify all fields that contain sensitive data, such as passwords, and add them to the Exclude sending payloads for parameters list. As an additional layer of security, tCell has a list of common sensitive field names such as passwd, password, and csrftoken. Agents will not send values of the parameters in either list to the tCellcloud, nor log them locally. This is independent of transmitting sanitized data

Agents always provide a sanitized version) of the request URI for App Firewall events to the service. If the Collect full (unsanitized) URIs option is enabled, tCell will also send the entire unsanitized URI to the tCell cloud, as it would appear in an access log.


The parameters in the "Exclude sending payloads for parameters" list and the default sensitive parameters WILL still be sent to tCell if this option is enabled and the URI contains them.

It’s possible to exclude specific routes and paths from being monitored for a specific pattern. Most commonly this is done when the pattern is generating too many false positives. To do this, on the right side of the pattern click on Add and enter the route or pattern to exclude.

Enabling XXE detection

XXE detection can be enabled in the App Firewall policy.

  1. Navigate to the Policies screen and click on the App Firewall tab.
  2. Scroll down to the section titled "XML External Entity (XXE)". Check the box labeled "Enabled".
  3. Users who want to catch all possible malicious XML payloads should check the box next to the default "tc-xxe-1" pattern, under "Regular Expressions (Pattern ID)". Advanced users may want to add and enable their own regular expressions.
  4. Click "Deploy" on the banner at the bottom of the screen. XXE detection can be enabled in the App Firewall policy.

FAQ: Can I enable XXE with no regular expressions?

Users must enable at least one XXE regular expression to see XXE events in tCell.

Allowlist Rules

The Allowlist Rules configuration option allows users to exclude certain requests from triggering tCell events, by matching regular expressions to request fields.

When should I configure an allowlist rule?

Allowlist Rules can be useful when a default tCell regex matches a request field value that is common or expected in your application. Instead of sifting through many false positive events, or excluding a specific request field entirely using Event Filtering, users can configure an allowlist rule that covers the expected values for that field.

How do I configure an Allowlist Rule?

The Allowlist Rules option is at the bottom of the App Firewall policy configuration page. There are multiple parts to an allowlist rule:

  1. An optional description
  2. Whether the rule is enabled or disabled. This can be toggled using the checkbox labeled "Enabled".
  3. A Route OR Path to match.
    • Routes: Any Route discovered by tCell in the current application can be selected using the dropdown, or the field can be left empty to match all Routes.
    • Paths: Select a request method, then enter the value of a Path. For allowlist rules, "Null Paths" do not apply and should not be used.
  4. A field on which to apply the regular expression. Select the field type (e.g. HTTP header, query parameter, etc) and enter the parameter name.
  5. A regular expression. Users can choose any regex previously defined in tCell, or create a new one. Make sure to click "Save selection" after selecting a regex.

To create a new rule, click "Add", fill in the form, then save the rule and deploy your changes.

Supported Versions

The following agent versions support Allowlist Rules:

  • JVM Agent >= 1.4.0

In which cases will an allowlist rule match a request?

For a request to match,

  1. The request must contain the field configured in the allowlist rule.
  2. The field's value must match the regex configured in the rule.
  3. Given an event with a specific Detection Point (e.g. XXS), the detection event must have been triggered by the field configured in the rule. If a Detection Point applies to another field in the request that is not configured in an allowlist rule, a corresponding event will still be sent.

For example, given the following rule:

GET /Query Param p_name.*tcell.*

This rule will match any GET requests to / with the query parameter p_name, if p_name's value contains tcell. Now consider the following request:

GET /?p_name=<script>alert(1);</script>tcell

The Allowlist Rule above matches this request, and the XSS event that would have been sent is ignored. Now consider a slightly different request:

GET /?p_name=tcell&other_p_name=<script>alert(1);</script>

In this case, an XXS event would still be sent, since the rule did not match the field which triggered the XXS event.

Suspicious Actors

This tab allows you to configure Suspicious Actor settings. You can select the Automatic blocking of Suspicious Actors mode that you prefer. All IPs currently identified by tCell as suspicious will be listed under Suspicious IPs.

Blocking Rules

This tab allows you to add URI paths or IP addresses to block from accessing your app. The IP denylist function is unrelated to the Automatic blocking of Suspicious Actors setting, and will work if the Blocking Rules Enabled option is selected.

You can add comments for any IP that you have added to the allowlist and denylist by clicking on the small note icon to the right of the IP.