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. 

To strengthen defenses against resource exhaustion and abuse, Wallarm has released two new mitigation controls specifically addressing "OWASP API4:2023 – Unrestricted Resource Consumption" threats.

📁 File Upload Restriction Policy 

This real-time node-side mitigation allows you to block oversized or maliciously crafted requests before they reach your app.

Two configuration options provide flexibility:

• Maximum Total Request Size – limit the full request, including headers, body, and parameters
  
  
• Maximum Size per Parameter – restrict specific fields such as JSON parameters, Multipart parameters, headers. etc.

This control is effective across all content types (e.g., POST-multipart, PUT, JSON with base64) and helps prevent denial-of-service, memory exhaustion, and CVE exploitation through size abuse.

Included in API Security and WAAP subscriptions with Node ≥ 6.3.0

🌐 Unrestricted Resource Consumption Detection

Part of the API Abuse detection module, this cloud-based control detects excessive and abnormal resource usage that may degrade system performance, even in the absence of traditional attack signatures.

Common attack scenarios include:

• Sending large requests to overload memory or bandwidth
  
  
• Triggering heavy operations (e.g., complex database queries) to slow down the server
  
  
• Downloading massive responses to consume outbound traffic (scraping) or exfiltrate data

Included in Advanced API Security (API Abuse module) with Node ≥ 6.3.0

🔍 Feature Comparison

✅ Full-Spectrum Protection for API4:2023

These two new controls, alongside Wallarm’s existing threat mitigation and behavioral detection capabilities, form a robust and layered defense against all known vectors of OWASP API4 Unrestricted Resource Consumption. 

In order to streamline the vulnerability management process and allow users to focus on actionable data, API Attack Surface Management (AASM) now automates the evaluation and updating of discovered Security Issues after each scan. Here’s how it works:

• After every scan, AASM compares the new scan results with the current state of each Security Issue.
• If the scan job completes successfully and changes are detected in the findings, the relevant Security Issue may be automatically closed or reopened.
• Each status update is logged in the Status History of the Security Issue.
• A comment is added to explain the reason for the change.

Possible closure reasons include:

• Port not found during last scan — the previously open port is now closed.
• Network service has changed — e.g., the service on the port changed, for example from SSH to HTTP.
• New version of the product detected — indicating a product upgrade.
• Vulnerable version no longer present — the outdated component has been removed
• Vulnerability not detected during last scan — the issue is no longer observable.

This feature automates and simplifies vulnerability management by updating issue statuses based on scan results, reducing manual effort and ensuring accurate, real-time tracking of security risks.

Additional information is available in the documentation.