API Protection Policies

The API Protection Policy enables you to monitor and disable threats targeting a predefined set of threat types that affect your APIs. This policy helps your security teams protect your application ecosystem from API attacks, such as JWT Anomalies, Session Violations, and Account Takeovers.

Key Features

The following are the features of the API Protection Policy tab:

Features	Description
Threat Type/Threat Rule List	It shows pre-defined API Protection rules categorized by Threat Types by default—for example, Session Violation.
Rule Information	Shows the following details for each rule: Info — Click the Info () icon to view the Description, Impact, Mitigation, and References of a Threat Rule/Type. Labels — Threat classification based on the OWASP API Security and CWE references.
Severity Levels	Shows the severity assigned to a rule, indicating the impact of the threat it detects.
Actions	It indicates the action that Traceable should take in response to the threat detected by the rule. You can configure the following actions for a rule: Monitor — Logs and monitors the threat, but does not block the request. Disable — Turns the rule off, which means no monitoring. While you can configure the above action for each threat rule, each Threat Type row shows the count of threat rules categorized by the configured action.
Status	Shows the current status of a Threat Type, Enabled or Disabled. Note Disabling a threat type disables all threat rules under it.
Filtering and Grouping	You can filter and/or group rules using the Filter () icon and Group By drop-down.

Policy Management

Policy management in Traceable follows a hierarchical structure, enabling or disabling policies at both environment-level and granular levels. You can manage the components within the API Protection policy tab at the following levels:

Environment Level — You can select the environment from the page’s top right corner and enable or disable the policy from the Status drop-down at the top of the tab. This enables or disables all the threat types collectively on the selected environment.
Note
Aggressive rules are disabled by default.
Threat Type Level — You can use the Toggle next to the Threat Type to enable or disable the threat rules under it. This enables or disables all the threat rules under it.
Threat Rule Level — You can use the Action drop-down next to a Threat Rule to enable (Monitor or Block) or disable (Disable) it.

While enabling the WAF policy at the environment level enables all threat types, you can also enable or disable the individual threat types/rules as required. Similarly, when you enable a threat type, you can manage the rules independently.

Overrides in Threat Type/Rule Actions

Modifying the action (enable or disable) for a threat type/rule in a specific environment overrides the default action set at the Environment Level. If you switch back to viewing the actions across All Environments, Traceable shows an Override () icon corresponding to the modified threat, which upon hovering, shows the environments in which the action has been customized.

For example, let’s say you set a Threat Rule to Block at the All Environments level, and you navigate to the Sandbox environment and change the action for the same rule to Monitor. Now, when you switch to All Environments from the Environment drop-down, Traceable, through the override icon shows that the global action has been overridden in the Sandbox environment.

Traceable, through the Override icon, ensures visibility into the environment-specific configurations, allowing you to track and manage threat types/rules effectively.

Understanding API Protection threat types

The following table lists and describes the various threat types that Traceable detects for API Protection:

Threat type	Description
Broken Access Control (Horizontal)	Horizontal Broken Access Control occurs when a user attempts to access resources or data belonging to another user with the same level of privilege. This typically results from insecure direct object references or insufficient authorization checks.
Broken Access Control (Vertical)	Vertical Broken Access Control occurs when a user attempts to access functionality or resources that require higher privileges than their assigned role. This indicates insufficient authorization checks and a potential attempt to perform administrative actions. For more information on configurations for Broken Access Control (Vertical), see the Security Scheme topic.
Broken Authentication	Broken Authentication occurs when authentication mechanisms are bypassed, exploited, or missing, allowing attempts to access an application without valid credentials.
Client-Side Trust Abuse	Client-side trust abuse occurs when an application improperly trusts client-provided data or requests without adequate validation. This can allow attackers to perform unauthorized actions or manipulate application behavior.
Content Anomaly	A Content Anomaly is detected when the content type or payload size of a request or response deviates from expected behavior. This includes unexpected Content-Type headers or unusually large payloads for a given endpoint.
GraphQL Attacks	GraphQL Attacks occur when requests violate GraphQL schema rules, such as using unknown fields, incorrect data types, or failing required constraints. For GraphQL attacks, you can configure certain parameters. Navigate to Protection → Policies → API Protection tab and click GraphQL Attacks. Next, click the three dots to view or edit the configuration as shown below.
JWT Violation	JWT Violation occurs when a JSON Web Token contains missing or incorrectly configured claims. Such misconfigurations can cause the token to behave differently than intended, leading to authorization issues.
Parameter Anomaly	Parameter Anomaly is detected when input parameters deviate from expected structure, encoding, type, or value ranges. Such anomalies may indicate probing activity, misconfigured clients, or injection attempts.
Schema Validation	Schema Validation anomalies occur when requests or responses do not conform to the defined schema, such as missing required fields, unknown parameters, incorrect data types, or invalid enum values. These deviations may indicate probing activity, misconfigured clients, or attempts to bypass security controls and are common in both REST and GraphQL APIs. For more information on schema validation configurations, see the Schema Validation topic.
Server-Side Trust Abuse	Server-side trust abuse occurs when attackers exploit the server’s ability to access internal or external systems on their behalf. By manipulating server-side features such as URL parameters, webhooks, or file fetches, attackers can force the server to make unauthorized requests. This can allow bypassing network controls and may lead to internal reconnaissance, credential exposure, data exfiltration, or further compromise of internal services.
Session Violation	A Session Violation occurs when session management mechanisms are compromised, allowing attackers to misuse or hijack user sessions. This can lead to unauthorized access, privilege escalation, or data exposure. Common causes include exposed session tokens, inadequate expiration or termination policies, missing session integrity validation, and session fixation using predefined or stolen tokens.