We have introduced configurable rate limiting in AASM to give customers greater control over scan intensity and to help protect their servers from excessive load.

🔧 What’s New

AASM now enables users to define maximum request rates across several dimensions:

• Per Tenant — limits the total number of requests per second sent to a client’s entire infrastructure.
• Per Domain — limits the requests per second for each domain and its subdomains.
• Per IP — limits the requests per second sent to each IP address, helping prevent unintended overload when multiple subdomains resolve to the same host.

Rate limits can be configured in the AASM “Configure” section. By default, no RPS limitations are enforced.

💡 Important Note

Applying rate limits may increase overall scan duration, depending on the configuration.

We’ve released a number of improvements to the Schema-Based Testing capabilities within the Wallarm platform.

Broken Authentication (OWASP API2) Testing

Schema-based Testing now includes extended coverage for Broken Authentication (OWASP API2) issues in OpenAPI-based scans. The new checks help uncover common weaknesses such as missing authentication enforcement, weak token validation, JWT tampering, and exposed credentials in query strings.

Running Tests Without a Test Policy

You can now run tests without creating a predefined Test Policy. All parameters for a test run can be provided directly at runtime, allowing scans to be executed entirely from the command line. This provides greater flexibility for integrating Wallarm testing into automated workflows and CI/CD pipelines.

The capability supports both OpenAPI and Postman-based scans, and the “Generate test run command” wizard helps quickly prepare the required Docker command.

Other Updates

Additional improvements make test management more transparent and configurable.

You can now define success criteria for each test run directly in the UI, specifying the severity level of security issues that will mark a test run as failed.

New status tracking and filtering options also make it easier to monitor progress and review results efficiently.

Schema-Based Testing is available as part of Wallarm Security Testing. Read more about Schema-Based Testing in the documentation. 

Wallarm now supports OpenAPI Specification (OAS) v3.1 for API specification enforcement. 

Customers using the API specification enforcement feature in Wallarm can now upload specifications in the OAS v3.1 format. Wallarm will correctly interpret the specification format and keywords. 

Read more about specification enforcement in the documentation. OAS v3.1 support requires node 6.6.1+. 

We’ve made observability simpler, faster, and more powerful for Security Edge customers! 

Starting today, you can view and filter your inline node logs directly inside the Security Edge Telemetry Portal, giving you immediate visibility into what’s happening across your API traffic in real time.

What’s New

You’ll now find a new dashboard under:

Telemetry Portal → Wallarm → Inline Node Logs

From there, you can explore both access logs and error logs with powerful built-in facets, including:

• region: view traffic by data center or PoP
• host: isolate activity for specific APIs or services
• request_method: focus on GET, POST, DELETE, and more
• nginx_status / upstream_status: identify failed requests and backend issues
• remote_addr / upstream_addr: trace requests from source to origin
• request_uri / req_id: drill into specific transactions or sessions

Each facet supports wildcard and regex matching, making it easy to narrow results and quickly find what you need, whether you’re troubleshooting, validating configuration changes, or analyzing API behavior.

Why It Matters

Before this improvement, inline node logs for Security Edge were only available through a support request.

Now, everything is available in one place, giving you:

• Faster troubleshooting without leaving the portal
• Unified visibility across all inline nodes
• Reduced operational overhead with no manual access or forwarding required

This Security Edge update brings greater transparency into the filtering layer, allowing your teams to diagnose issues and validate traffic handling directly from the Telemetry Portal.

The Security Issues page is now the centralized point for storing and tracking vulnerabilities detected by any module of the Wallarm platform. The previous Vulnerabilities section in the Events is now deprecated.

This unified section consolidates data from:

• AASM (Advanced API Security / API Attack Surface Subscription)
  
  
• Schema-Based Testing (Security Testing subscription)
  
  
• Threat Replay Testing (Advanced API Security and Security Testing subscriptions)
  
  
• Passive Detection (WAAP and Advanced API Security subscription)
  
  

All vulnerabilities are unified, classified, and prioritized according to a single methodology, enriched with CWE and OWASP classifications. The Security Issues page provides statistics charts, flexible filters, including negative filters, and bulk actions for efficient vulnerability management.

Vulnerability management actions, such as marking false positives, closing, reopening, or commenting, are now standardized across all detection sources. The Historical and Resolution charts aggregate data from multiple modules, and the “Discovered by” filter allows users to view security issues originating from specific components. Read more in the documentation. 

We’re continually working to expand and maintain our deployment options for Wallarm filtering nodes. We have three updates to share regarding connector-based integrations. 

New Azure APIM Connector:

For customers with APIs managed by Azure APIM, Wallarm now offers a new connector to collect relevant API traffic for analysis. This connector can be deployed in both synchronous and asynchronous modes. 

Read more about our Azure APIM connector in the documentation. 

Updated Apigee Connector: 

Wallarm has updated our existing Apigee connector to parse and analyze API responses in addition to requests. This change expands the Wallarm features supported by the connector. 

Read more about our Apigee connector in the documentation. 

Updated Akamai Connector: 

Wallarm has updated our existing Akamai connector to parse and analyze API responses in addition to requests. This change expands the Wallarm features supported by the connector. 

Read more about our Akamai connector in the documentation. 

Wallarm delivers outstanding automated attack protection, but there are situations where you want to create custom criteria, rules, and thresholds for taking action. Previously, these capabilities were distributed within Wallarm rules and triggers, making it complicated to manage. In order to streamline the process of configuring and managing custom response actions, Wallarm has introduced Mitigation Controls. 

You can find Mitigation Controls as a separate menu item in the Security Controls section of the menu. The new Mitigation Controls capability brings together a collection of response options in a centralized, easy to manage interface. Here you can configure capabilities like blocking modes, GraphQL policies, custom BOLA protection, and more. 

The configuration and response options available for each mitigation control vary based on the control, providing you with the information you need to generate the mitigation results you want. Mitigation Controls are available with node 6.5.x+. Existing customers with configured triggers for Brute Force, Forced Browsing, and BOLA will be individually migrated once all nodes are compatible. Read more about each mitigation control and their configurations in the Wallarm documentation.

Attackers are evolving — rotating IPs, spreading abuse across multiple requests, and bypassing traditional defenses. In this environment, simply detecting attacks is not enough. Security teams need precise tools to stop attacks without breaking customer experiences.

With the introduction of session-based blocking, Wallarm gives customers surgical control over active attacks. This capability allows teams to terminate compromised API sessions in real time, even when attackers switch IPs or distribute activity, while keeping legitimate users unaffected.

Wallarm now offers three advanced options for active attack mitigation:

• Block Individual Requests — Instantly shut down malicious requests such as SQL injection, RCE, and path traversal exploits.
• Block IP Addresses — Eliminate abusive IPs proactively or reactively when needed.
• Block Compromised Sessions (New) — Target and terminate malicious sessions to neutralize sophisticated, multi-request API abuse.

Unlike traditional IP-based blocking, session-based blocking focuses on attacker behavior, not network location. It enables security teams to stop ongoing attacks with granular precision, preserving user experience while strengthening API defenses.

Users can enable API session blocking in their API Abuse Prevention profiles and in specific Mitigation Controls. 

You can read more about using session-based blocking in the Wallarm documentation. 

We’re excited to announce that Schema-Based Testing is now generally available as part of the Wallarm Security Testing suite.

This release introduces Dynamic Application Security Testing (DAST) for APIs, enabling shift-left API testing and seamless integration into CI/CD pipelines and the SDLC process.

Key Highlights

Expanded Vulnerability Coverage:

• OWASP API Top 10 risks
• Business Logic flaws (BOLA, BFLA)
• Input validation issues (Injections, RCE, Path Traversal)
• Environment misconfigurations
• GraphQL misconfigurations

Supported Inputs:

• OpenAPI specifications
• Postman collections (for advanced testing of business logic scenarios and access control violations)

Schema-Based Testing runs on a lightweight Docker-based agent, ensuring fast and isolated execution. It supports both one-time scans for quick assessments and continuous testing integrated into CI/CD pipelines, making it flexible for different stages of the development lifecycle.

Test results are available locally for immediate review and are also synced to the Wallarm Console, where issues can be tracked and prioritized. Users can define a configurable risk-level threshold to automatically determine when a test run should fail, aligning security checks with organizational policies. You can learn more in the Wallarm documentation.

Attackers continue to adapt and Wallarm continues to innovate API protection. We’ve introduced improvements to API Abuse Prevention in order to improve detection of Account Takeover (ATO) attacks. Wallarm now supports two additional machine learning detectors. 

IP Rotation

The IP rotation detector identifies account takeover attacks where attackers utilize a pool of IP addresses to perform an attack. In these types of attacks, the session remains stable, with cookies, headers, and other key fields unchanged, but each request or a small set of requests is made from a different IP address, often using each IP only once. This results in a single long session involving multiple IPs.

The detector analyzes this IP diversity within a consistent session to flag sophisticated automated attacks that evade traditional security measures.

Session Rotation

The Session rotation detector identifies account takeover attacks where attackers rotate session identification to avoid detection. In these types of attacks, a unique session (e.g., a cookie-based ID) is assigned to each client, but an attacker intentionally modifies or removes the session identifier. This results in one attacker using a single IP address with multiple sessions.

The detector analyzes this unusual behavior of high session diversity from the same IP to detect sophisticated automated attacks.

Both of these new detectors were created to better identify anomalies in API traffic that indicates an account takeover attack. You can read more about API Abuse Prevention in the documentation.