Regex Threat Protection¶

Overview¶

Regex Threat Protection in Yappes blocks malicious or unwanted patterns in API traffic at the gateway — including URI paths, query parameters, HTTP headers, and form data — using configurable regular expression rules.

This feature helps organizations to:

Block SQL injection, script injection, and other pattern-based attacks at the gateway
Validate URI paths, query strings, headers, and form fields without backend changes
Apply different rules for request and response contexts per endpoint
Complement JSON Threat Protection and XML Threat Protection with pattern-based defense

When applied at the API or subscription level, Regex Threat Protection blocks malicious patterns in URI paths, query parameters, HTTP headers, and form data at the Yappes Gateway before traffic reaches backend services.

Regex Threat Protection aligns with OWASP API Security best practices for input validation and attack pattern detection.

When to Use Regex Threat Protection¶

Use Regex Threat Protection when:

You need to block known attack patterns (e.g. SQL keywords, script tags) in URI, query, headers, or form data
APIs accept JSON, form-encoded, or XML content and require pattern validation beyond structural limits
You want separate request and response regex rules per endpoint
GET endpoints need request-context pattern checks on URI, query, or headers (unlike JSON/XML threat protection)

When Not to Use Regex Threat Protection¶

Avoid using Regex Threat Protection in the following scenarios:

You only need JSON size/depth limits (use JSON Threat Protection)
You only need XML element/attribute limits (use XML Threat Protection)
Payload field structure and data types must be enforced (use Schema Validation)

Prerequisites¶

Before configuring Regex Threat Protection policies, ensure the following requirements are met.

Required Access and Permissions¶

Common Requirements¶

Active Yappes platform account
API Manager access
Permission to create and manage Gateway Policies
At least one API created under My APIs

API Level¶

Endpoint content type is application/json, application/x-www-form-encoded, or application/xml
Configuration format (JSON or XML) is chosen automatically based on endpoint content type

Subscription Level¶

API must be published
An active subscription must be available on the Manage Subscriptions page

System Requirements¶

Supported web browser: Chrome, Edge, or Firefox

Regex Configuration¶

Regex Threat Protection is configured in a code editor labeled Regex Configuration. The default template format depends on endpoint content type:

JSON endpoints — JSON object with a rules array
XML endpoints — XML <RegexThreatProtection> document with <Rules>

A default template loads when you select Context (Request or Response).

Rule Properties¶

Property	Required	Description
`enabled`	Yes	Turns threat protection on or off
`continueOnError`	Yes	If `true`, traffic proceeds even when a pattern matches
`type` / `<Type>`	Yes	Must be `regexThreatProtection`
`name` / `<Name>`	Yes	Policy configuration name
`rules` / `<Rules>`	Yes	Array/list of regex rules

Rule Object Properties¶

Property	Required	Description	Example
`targetType`	Yes	Where to apply the pattern	`uriPath`, `queryParam`, `header`, `formData`
`targetExpression`	For queryParam, header, formData	Name of the parameter, header, or form field	`id`, `Authorization`, `username`
`patterns`	Yes	List of regex patterns to block when matched	`["drop\\s*table", "<script>"]`

Target Types¶

targetType	Applies To	targetExpression
`uriPath`	Request URI path	Not required
`queryParam`	Query string parameter	Parameter name (e.g. `id`)
`header`	HTTP header	Header name (e.g. `Authorization`)
`formData`	Form field in request body	Field name (e.g. `username`)

Info

On GET endpoints, the default template removes the formData rule automatically because GET requests do not carry a form body. Request context is allowed on GET for Regex Threat Protection (unlike JSON and XML threat protection).

Default JSON Template Example¶

{
  "type": "regexThreatProtection",
  "name": "Regex-Threat-Protection-1",
  "enabled": true,
  "continueOnError": false,
  "rules": [
    {
      "targetType": "uriPath",
      "patterns": [
        "drop\\s*table",
        "^EMP[0-9]{5}$"
      ]
    },
    {
      "targetType": "queryParam",
      "targetExpression": "id",
      "patterns": ["(or\\b)"]
    },
    {
      "targetType": "header",
      "targetExpression": "Authorization",
      "patterns": ["<script>"]
    },
    {
      "targetType": "formData",
      "targetExpression": "username",
      "patterns": ["admin"]
    }
  ]
}

Default XML Template Example¶

<RegexThreatProtection>
  <Type>regexThreatProtection</Type>
  <Name>Regex-Threat-Protection-1</Name>
  <Enabled>true</Enabled>
  <ContinueOnError>false</ContinueOnError>
  <Rules>
    <Rule>
      <TargetType>uriPath</TargetType>
      <Patterns>
        <Pattern>drop[ \t\r\n]*table</Pattern>
        <Pattern>^EMP[0-9]{5}$</Pattern>
      </Patterns>
    </Rule>
    <Rule>
      <TargetType>queryParam</TargetType>
      <TargetExpression>id</TargetExpression>
      <Patterns>
        <Pattern>(^|[^A-Za-z0-9_])or([^A-Za-z0-9_]|$)</Pattern>
      </Patterns>
    </Rule>
  </Rules>
</RegexThreatProtection>

Custom error and message

For error scenarios, you can override the default HTTP status code, error code, and message. See Custom Error and Message.

Step-by-Step Implementation¶

Method 1: Creating Regex Threat Protection from the Endpoint Tab¶

Step 1: Navigate to API Manager¶

Click on Manage APIs in the main dashboard.
Select My APIs from the submenu.

Step 2: Open Your API and Select an Endpoint¶

For a new API, follow onboarding steps and open endpoint details.
For an existing API, select it from My APIs and click the target endpoint.

Step 3: Open Regex Threat Protection Tab¶

Click the Regex Threat Protection tab on the endpoint details panel.
Click Regex Threat Protection to create a new policy, or Edit / View on an existing attached policy.

Step 4: Enter Policy Details¶

Enter a descriptive Policy name (e.g. BlockSqlInjectionPatterns).
Add a Description (max 500 characters).
Select API and endpoint fields are read-only.

Step 5: Select Context and Configure Regex Rules¶

Select Context — Request or Response (both available on GET endpoints).
Edit Regex Configuration in the editor (JSON or XML based on content type).
Refer to Regex Configuration for rule structure.

Step 6: Create the Policy¶

Review the configuration.
Click Create policy (or Save when editing).
Expected Result: The policy is attached to the endpoint.

Info

Each endpoint can have one request and one response Regex Threat Protection policy.

Method 2: Creating Regex Threat Protection from Gateway Policies Page¶

Step 1: Navigate to Gateway Policies¶

Locate Gateway Control → Gateway Policies in the main navigation menu.

Step 2: Configure Policy Settings¶

Click Create Policy.
Select the appropriate Control Level based on where the policy is required:
API Level — Applies Regex Threat Protection to a specific API endpoint at creation.
Subscription Level — Creates a reusable policy for attachment to consumer subscription endpoints.
In Policy Type, select Regex Threat Protection.

For general policy creation guidance, see Creating a policy (w/edit and delete).

Step 3: Define Policy Details¶

Enter Policy Name and Description.

Step 4: Select API and Endpoint (API Level Only)¶

If Control Level is set to API Level:
Select the target API and Source endpoint (or Operation for SOAP APIs).
If Control Level is set to Subscription Level:
No API or endpoint selection is required.

Step 5: Select Context and Configure Regex Rules¶

Select Context — Request or Response (both available on GET endpoints at API Level).
Edit Regex Configuration in the editor. Refer to Regex Configuration for rule structure.

Info

At Subscription Level, both Request and Response context are available during policy creation. When attaching to GET endpoints, Request context is allowed but formData rules are not applied because GET requests do not carry a form body.

Step 6: Create the Policy¶

Review all settings.
Click Create Policy.

Success

The Regex Threat Protection policy is successfully created.

Attaching Regex Threat Protection Policy to Subscriptions¶

Use this flow when you created a policy with Control Level set to Subscription Level in Gateway Policies.

Step 1: Navigate to Manage Subscriptions¶

From the main menu, click Manage Subscriptions.
The Manage Subscriptions page displays a list of all API subscriptions.
Locate the subscription where you want to apply the Regex Threat Protection policy.

Step 2: Open the Policy Attachment Dialog¶

Click Attach or Detach for the relevant subscription.
The policy attachment dialog opens.

Step 3: Select Endpoint Level¶

In the Attach Policy tab, select Endpoint Level.
Regex Threat Protection policies do not appear when API Level is selected. The platform shows: "Custom Plugin, JSON, XML and Regex Threat Protections are not listed and cannot be attached at API level."

Step 4: Select Endpoints¶

Select one or more endpoints from the endpoint list.
Regex Threat Protection supports endpoints with application/json, application/x-www-form-encoded, or application/xml content type.
After selecting endpoints, proceed to the policy selection step.

For general attach and detach steps, see Manage Subscriptions — Attach/Detach Gateway Policies.

Step 5: Select and Attach the Policy¶

In Select Policy to Attach, choose your subscription-level Regex Threat Protection policy.
Click Save Changes to apply the policy to the selected endpoints.

Note

Only one policy of the same type can be attached to a subscription at a time. Detach the existing policy before attaching a replacement.
Each endpoint supports at most one request and one response Regex Threat Protection policy.

Understanding the Interface¶

Component	Description
Policy Name	Identifies the Regex Threat Protection policy
Description	Documents the policy purpose
Context	Request or Response — where patterns are evaluated
Regex Configuration	Code editor for JSON or XML regex rules
Control Level	API Level (single endpoint at creation) or Subscription Level (attach via Manage Subscriptions)

Control Level Summary¶

Control Level	API/Endpoint at Creation	Attach Path
API Level	Required	Endpoint tab or Gateway Policies (auto-attached to selected endpoint)
Subscription Level	Not required	Manage Subscriptions → Endpoint Level

Configuration and Settings¶

Required Configuration Fields¶

Field	Requirement	Description
Policy Name	Mandatory	Min 3 characters; must start with a letter
Description	Optional	Max 500 characters
Control Level	Mandatory	API Level or Subscription Level
API Selection	Mandatory at API Level	Target API; not required at Subscription Level
Endpoint Selection	Mandatory at API Level	Specific endpoint for enforcement; not required at Subscription Level
Context	Mandatory	Request or Response
Regex Configuration	Mandatory	Valid JSON or XML with at least one rule

Info

Unlike JSON Threat Protection and XML Threat Protection, Regex Threat Protection allows Request context on GET endpoints for URI path, query parameter, and header pattern checks.

Each endpoint supports at most one request and one response Regex Threat Protection policy.

On GET endpoints, formData rules are removed from the default template automatically.

Best Practices for Configuration¶

Best Practice	Benefit
Start with the default template and add rules incrementally	Avoids over-blocking legitimate traffic
Test regex patterns in non-production before rollout	Prevents false positives on valid requests
Use specific `targetExpression` for queryParam, header, and formData	Applies patterns only where intended
Keep `continueOnError` as `false` in production	Ensures matched patterns block traffic
Combine with JSON or XML Threat Protection	Structural limits plus pattern-based defense

What Happens If a Request Is Blocked¶

If Regex Threat Protection matches a configured pattern:

The request or response is blocked at the API Gateway (unless continueOnError is true)
The backend service is not invoked for blocked requests
The client receives a threat protection error response
The failure is logged for monitoring and audit purposes

Verification and Testing¶

After configuring Regex Threat Protection:

Send a request that does not match any blocked pattern and confirm success.
Send a request with a URI, query, header, or form value that matches a pattern and confirm the gateway blocks it.
On GET endpoints, verify request-context rules apply to URI, query, and headers (not formData).
Confirm separate request and response policies when both are configured.

Troubleshooting¶

Issue	Possible Cause	Resolution
Regex Threat Protection tab not visible	Unsupported content type on endpoint	Use JSON, form-encoded, or XML content type
Cannot create second policy	Request or response slot already filled	Edit existing policy or choose the other context
Configuration save fails	Invalid JSON or XML in editor	Fix syntax errors shown in the editor
Legitimate requests blocked	Regex too broad	Refine patterns; test with sample traffic
formData rule missing on GET	Expected behavior	GET has no form body; formData is stripped from template
Wrong editor format (JSON vs XML)	Endpoint content type drives format	XML endpoints use XML template; others use JSON

Impact of Policy Changes¶

Adding or tightening regex patterns may block previously accepted requests.
Removing patterns may allow attack strings through the gateway.
Changing continueOnError affects whether matches block traffic or only log.
Always test updates in non-production before deploying to production.

❓ Frequently Asked Questions¶

How many Regex Threat Protection policies can I attach per endpoint?
One request and one response policy per endpoint.

Is Regex Threat Protection available at subscription level?
Yes. Create the policy with Control Level set to Subscription Level in Gateway Policies, then attach it via Manage Subscriptions at Endpoint Level. See Attaching Regex Threat Protection Policy to Subscriptions.

JSON or XML configuration — which do I use?
The editor format is chosen by endpoint content type: XML endpoints use the XML template; JSON and form-encoded endpoints use the JSON template.

Does Regex Threat Protection replace JSON or XML Threat Protection?
No. Regex blocks patterns in URI, query, headers, and form data. JSON and XML Threat Protection limit payload structure size and depth. They complement each other.

Pro Tip

Regex Threat Protection in Yappes blocks attack patterns at the API Gateway before they reach your backend. Use the default template as a starting point, test patterns carefully, and combine with JSON Threat Protection or XML Threat Protection for full coverage.