Skip to main content
Feedback

Usage

Review the following considerations when configuring the Regex Threat Protection policy:

  • This policy supports only pre-processing, so the Pre-processing field must be configured for this policy to function.

  • It inspects all requests regardless of Content-Type. Unlike the JSON and XML Threat Protection policies, there is no content-type filtering, the configured checks apply to all incoming requests.

  • At least one of checkHeaders, checkPath, or checkBody must be true for any inspection to occur. With all three set to false (the default), every request passes through regardless of the regex value.

  • When multiple scopes are enabled, the policy evaluates headers first, then path and query parameters, then body. Evaluation stops at the first match found.

  • The URL path and query parameter values are URL-decoded before matching. Query parameter keys are not decoded.

  • Matching is case-insensitive by default (caseSensitive=false). Use this default to catch mixed-case attack variants such as DrOp TaBlE. Only enable caseSensitive=true when your use case specifically requires exact-case matching.

  • It helps to detect SQL injection attempts across any part of the request (headers, query string, body).

  • It lets you block cross-site scripting (XSS) payloads. For example, <script> tags or JavaScript event handlers.

  • It prevents Java class injection (java.lang.Runtime.exec), LDAP injection, command injection (; rm -rf /), or path traversal patterns (../../../etc/passwd).

  • When your API accepts requests of any content type and you need a single pattern to apply universally.

  • It is useful for APIs that need OWASP API Security alignment for API8:2023 (Injection).

  • The policy is protected against DoS (Denial of Service) attacks, where a complex or malicious regex pattern could cause the system to slow down or stop responding. To prevent this, the regular expression evaluation automatically stops if it takes longer than the allowed request timeout.

  • The policy is optimized for minimal memory usage and efficiently processes request bodies, even under high request volumes.

Pattern examples

The following are common use cases and example regex patterns. As this policy uses full-string matching, all patterns are wrapped with .* to detect the target string anywhere within the evaluated input.

  • Usecase 1: SQL injection (any case) - For example, .*(?i)(SELECT|INSERT|UPDATE|DELETE|DROP|UNION|EXEC).*

  • Usecase 2: XSS script tag - For example, .*<script.*

  • Usecase 3: Java class injection - For example, .*java\.lang\.Runtime.*

  • Usecase 4: Path traversal - For example, .*\.\./.*

  • Usecase 5: LDAP injection - For example, .*\(cn=.*\).*

  • Usecase 6: Command injection - For example, .*;\s*(rm|cat|chmod|curl|wget).*

Chaining with other policies

You can combine the Regex Threat Protection policy with other processors on a single endpoint using Mashery_Proxy_Processor_Chain. To configure a chain on the Call Transformation page, enter the adapter identifiers as a comma-separated list in the processors key. For each adapter's individual configuration parameters, use the format <processor-name>.<config-name>: <config-value>.

Example

Data to make available for pre-processing

The following is an example value for Data to make available for pre-processing field. It chains the JSON Threat Protection policy with the Regex Threat Protection policy:

processors: com.mashery.proxy.protection.json-threat-protection,com.mashery.proxy.protection.regex-threat-protection
com.mashery.proxy.protection.json-threat-protection.maxDepth: 10
com.mashery.proxy.protection.regex-threat-protection.regex: .*(?i)(SELECT|DROP|UNION).*
com.mashery.proxy.protection.regex-threat-protection.checkHeaders: true
com.mashery.proxy.protection.regex-threat-protection.checkPath: true
com.mashery.proxy.protection.regex-threat-protection.checkBody: true

Refer to Chaining Processors for a full overview of chaining types and adapter compatibility.

On this Page