Skip to content

XML Threat Protection

Overview

XML Threat Protection in Yappes guards XML payloads at the API Gateway against oversized documents, excessive element counts, and deeply nested structures that can indicate denial-of-service or injection attacks.

This feature helps organizations to:

  • Limit XML element count, attribute count, and nesting depth before requests reach backend services
  • Block malicious or abnormally large XML structures early in the request lifecycle
  • Protect backend systems from XML-based abuse without changing application code
  • Enforce consistent structural limits across XML API endpoints

When applied at the API or subscription level, XML Threat Protection enforces structural limits on XML payloads at the Yappes Gateway before they reach backend services.

XML Threat Protection aligns with OWASP API Security best practices for input validation and payload size control.

When to Use XML Threat Protection

Use XML Threat Protection when:

  • APIs accept XML request or response payloads (application/xml)
  • You need to cap element count, attribute count, text length, or nesting depth at the gateway
  • Backend services should be protected from oversized or deeply nested XML
  • You want separate request and response limits per endpoint

When Not to Use XML Threat Protection

Avoid using XML Threat Protection in the following scenarios:

Prerequisites

Before configuring XML 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/xml
  • For GET endpoints, only Response context is supported (no request body)

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

XML Configuration

XML Threat Protection is configured in a code editor labeled XML Configuration. A default template is loaded when you select Context (Request or Response). Edit the XML document to set limits for your endpoint.

Configuration Elements

Element / Attribute Required Description Default
enabled Yes Turns threat protection on or off for this policy true
continueOnError Yes If true, the request proceeds even when evaluation fails false
name Yes Internal name for the protection configuration XML-Threat-Protection-1
DisplayName Yes Human-readable display name XML Threat Protection
ElementCount Yes Maximum number of XML elements allowed in the document 200
AttributeCount Yes Maximum number of attributes allowed 100
TextNodeLength Yes Maximum length of text node content 1000
ContainerDepth Yes Maximum nesting depth of XML elements 15

Default Template Example

<XMLThreatProtection
    enabled="true"
    continueOnError="false"
    name="XML-Threat-Protection-1">

    <DisplayName>XML Threat Protection</DisplayName>
    <ElementCount>200</ElementCount>
    <AttributeCount>100</AttributeCount>
    <TextNodeLength>1000</TextNodeLength>
    <ContainerDepth>15</ContainerDepth>

</XMLThreatProtection>

Note

  • Click the Expand icon to open the editor in full-screen mode for easier editing.
  • The configuration must be valid XML.

Info

When an endpoint uses an XML-compatible content type, the platform shows: "This endpoint uses XML-compatible content type, so only XML Threat Protection is available." in the JSON Threat Protection context on the Gateway Policies page.

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

Accessing My APIs

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.
  • The endpoint must use content type application/xml.

Accessing Endpoints

Step 3: Open XML Threat Protection Tab

  • Click the XML Threat Protection tab on the endpoint details panel.
  • Click XML 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. SoapOperationXmlResponseProtection).
  • Add a Description (max 500 characters).
  • Select API and endpoint fields are read-only.

Step 5: Select Context and Configure XML

  • Select Context — Request or Response.
  • On GET endpoints, only Response is available.
  • Edit the XML Configuration in the editor. Refer to XML Configuration for element details.

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 XML Threat Protection policy. On GET endpoints, you can attach one response policy only.

Method 2: Creating XML Threat Protection from Gateway Policies Page

Step 1: Navigate to Gateway Policies

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

navigate to Gateway Policies

Step 2: Configure Policy Settings

  • Click Create Policy.
  • Select the appropriate Control Level based on where the policy is required:
  • API Level — Applies XML 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 XML 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).
  • XML Threat Protection is shown when the endpoint content type is application/xml.
  • If Control Level is set to Subscription Level:
  • No API or endpoint selection is required.

Step 5: Select Context and Configure XML

  • Select Context — Request or Response.
  • On API Level with a GET endpoint, only Response is available.
  • Edit XML Configuration in the editor. Refer to XML Configuration for element details.

Info

At Subscription Level, both Request and Response context are available during policy creation. GET endpoint restrictions apply when you attach the policy to endpoints in Manage Subscriptions — request-context policies are not listed when a GET endpoint is selected.

Step 6: Create the Policy

  • Review all settings.
  • Click Create Policy.

Success

The XML Threat Protection policy is successfully created.

Attaching XML 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 XML Threat Protection policy.

Navigate to Manage Subscriptions

Step 2: Open the Policy Attachment Dialog

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

Attach the Policy to Subscriptions

Step 3: Select Endpoint Level

  • In the Attach Policy tab, select Endpoint Level.
  • XML 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.
  • Only endpoints with application/xml, text/xml, or *+xml content type are compatible with XML Threat Protection policies.
  • If a GET endpoint is among your selection, Request context policies are not available for attachment.
  • After selecting endpoints, proceed to the policy selection step.

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

Step 4 Select Endpoints (if Endpoint Level)

Step 5: Select and Attach the Policy

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

Select and Attach the Policy

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 XML Threat Protection policy.

Understanding the Interface

Component Description
Policy Name Identifies the XML Threat Protection policy
Description Documents the policy purpose
Context Request or Response — where limits are enforced
XML Configuration Code editor for XML limit settings
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
XML Configuration Mandatory Valid XML with configured limits

Info

GET endpoints do not support Request context for XML Threat Protection. The platform shows: "Get endpoint can not have request context" and limits you to Response only.

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

Best Practices for Configuration

Best Practice Benefit
Start with default limits and tune based on real SOAP/XML traffic Reduces false blocks while maintaining protection
Set separate request and response policies when payload sizes differ More precise control per direction
Keep continueOnError as false in production Ensures limits are strictly enforced
Test with oversized XML documents in non-production Confirms blocking behavior before rollout
Use Regex Threat Protection for URI/header pattern blocking Complements structural XML limits

What Happens If a Request Is Blocked

If XML Threat Protection detects a limit violation:

  • 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 XML Threat Protection:

  • Send an XML payload within configured limits and confirm the API responds successfully.
  • Send XML that exceeds element count, attribute count, or depth limits and confirm the gateway blocks it.
  • Confirm separate request and response policies apply when both are configured.
  • On GET endpoints, verify only response context is enforced.

Troubleshooting

Issue Possible Cause Resolution
XML Threat Protection tab not visible Endpoint content type is not application/xml Use an XML content type endpoint
Cannot select Request context Endpoint method is GET Use Response context only
Cannot create second policy Request or response slot already filled Edit existing policy or choose the other context
Configuration save fails Invalid XML in editor Fix syntax errors shown in the editor
Requests blocked unexpectedly Limits too strict for legitimate payloads Increase values in XML Configuration
JSON Threat Protection shown instead Wrong content type on endpoint Confirm endpoint uses application/xml

Impact of Policy Changes

  • Tightening limits may cause previously accepted XML payloads to fail.
  • Relaxing limits may allow larger or deeper XML documents through the gateway.
  • Changing continueOnError affects whether violations block traffic or only log.
  • Always test updates in non-production before deploying to production.

❓ Frequently Asked Questions

How many XML Threat Protection policies can I attach per endpoint?
One request and one response policy per endpoint. GET endpoints support response only.

Is XML 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 XML Threat Protection Policy to Subscriptions.

Does XML Threat Protection validate against XSD?
No. It enforces structural limits (element count, depth, text length), not full schema validation.

What content types support XML Threat Protection?
Endpoints with application/xml content type.

Can I use XML Threat Protection on SOAP APIs?
Yes. SOAP endpoints typically use XML content type. The UI shows Operation instead of Endpoint for SOAP APIs.

What is the difference between XML and JSON Threat Protection?
JSON Threat Protection applies JSON-specific limits. XML Threat Protection applies element, attribute, and depth limits on XML documents.

Pro Tip

XML Threat Protection in Yappes enforces structural limits on XML payloads at the API Gateway. Use it on SOAP and XML endpoints, start with the default template, and pair with Regex Threat Protection for pattern-based defense on URI and headers.