Tracked as CVE-2026-32475 (CVSS score of 9.8), the bug described as an arbitrary file upload issue in the function that handles form submissions.
The post Elementor Pro WordPress Plugin Vulnerability Exploited to Hack Sites appeared first on SecurityWeek.
Short version: an MCP server is the tooling layer that lets an AI agent act on external systems. Hosted remotely, it is an API endpoint like any other — and it needs bot and WAF controls in front of it, API security on its own endpoints, and AI guardrails that inspect what the tools send back, not just what the user types in.
Not since the dot-com boom in the late 1990s has the world seen a more highly talked-about and sought-after tech revolution. Artificial Intelligence has entered every aspect of our lives – from building large scalable applications to your Monday morning Macchiato.
With this spread of wildly varying use cases, one thing became abundantly clear. Large Language Models have isolated context, which is limited to the training data and the inputs provided by a user. To expand this knowledge, we need to provide AI Agents with appropriate tooling to retrieve such information. A curl tool to view a webpage, a directory listing tool to retrieve files from a folder, or a git CLI tool to commit changes to a repo.
Humans need tools as well. We don’t sift through HTML code, read JSON responses or query API endpoints via the command line. Rather we rely on well-thought-out and structured UX components – icons, text fields, buttons, and checkboxes – all of which are wired into various functions and APIs in the backend.
AI Agents, however? They rely on different types of tools. Given that every single one of the billions of websites and applications on the Internet today works and operates differently, these tools need to cater to them. Sites have been built on everything ranging from PHP and ASP to Node and Express. The question becomes – how can I ensure my agent reliably interacts with each of these sites? You could argue that these days, most applications expose a lot of their functionality via APIs. And you would be right. While AI Agents can easily consume these APIs, it involves a few different steps –
All these steps, every single time. Every site, every application, requiring its own “code” built by the AI Agent. With limited context windows and larger thinking models, this can get out of hand quickly – both in terms of token count and time taken – for every single user prompt.
Enter the MCP Server. An MCP server is a standardized service that exposes a defined set of tools, resources and prompts to an AI agent over the Model Context Protocol, so the agent can act on an external system without hand-written glue code for every API. Developed by Anthropic, the Model Context Protocol was built as an open-source standard for connecting AI Applications to external systems. It was released in November 2024 and contributed to the Linux Foundation’s Agentic AI Foundation in December 2025; by that point more than 10,000 MCP servers had been published. In essence, providing the AI Agent the right tools and resources, for each of these applications, to help abstract away the complexity of each of these interactions. Think of it as a USB-C port for your AI Agent – one connector, and every application on the other side just works!
What can MCP Servers allow your agent to do? The use cases are endless and constantly expanding every day – from searching and booking flights to reviewing stock prices and executing trades (this is not financial advice!). MCP Servers give your AI Agent the tools it needs to do more than just be your information chatbot.
But all this functionality exposes a glaringly obvious security blind spot. Who is protecting your MCP Server, which now has tools exposed to action any of these tasks? Who is governing what can be asked of your AI Agent which now has access to these tools? The security implications are massive.
This is not theoretical. Imperva’s threat research team documented a critical remote code execution flaw (CVE-2025-53967) in the widely used Framelink Figma MCP server — an open-source project with more than 10,000 GitHub stars — and OWASP’s Gen AI Security Project published A Practical Guide for Secure MCP Server Development in February 2026 because the same weaknesses keep recurring. The MCP specification’s own security guidance now names token passthrough, session hijacking, the confused deputy problem and SSRF as first-class MCP risks.
Now, not every MCP Server carries the same exposure. Plenty of them run locally – a process on your laptop, talking to your agent over stdio, never touching a network. The risk there is real, but it’s a different conversation: credentials sitting in a config file, and how much that server is allowed to reach on your behalf. The moment an MCP Server goes remote though – hosted, over HTTP, serving agents across the Internet – it stops being a local utility and becomes what it always really was underneath: an API endpoint. Exposed, authenticated, and waiting to be probed. That’s the one you can put controls in front of.
This is where Thales’s focus has been for the past several months. For decades, Thales Imperva has been at the forefront of securing sites and applications, and with the evolution of applications and their users, we’ve enabled our solutions to cover these use cases and the complex threat landscape.
Automated traffic is the baseline condition here, not the exception. Imperva’s 2026 Bad Bot Report found that bots accounted for more than 53% of all web traffic in 2025, up from 51% the year before — and that 27% of bot attacks targeted API endpoints. A remote MCP server is an API endpoint, so it inherits that traffic profile the moment it goes live. Knowing which AI bots to allow and which to block is the first control, not the last.
The Thales Imperva Cloud WAF and Advanced Bot Protection provide visibility into automated traffic heading towards the MCP Server, preventing generally malicious bot traffic and more exploitative OWASP Top 10 attack classes like command injection and SQL injection.
Thales Imperva API Security ensures your MCP Server has its own endpoints secured against everything from simple schema exploitation to complex business logic attacks. (For the wider picture of agents as API consumers, see API security for AI agents.)
Finally, our AI Application Security puts in place guardrails that sit between the AI Agent and the model behind it, securing the workflow against LLM-specific attacks like prompt injection, system prompt leakage and jailbreak attempts. And critically for MCP – it inspects what comes back from the tools, not just what goes in. Today, most people worry about user prompts. Far fewer are watching the tool response. Because an instruction buried in a log entry or an incident description can quietly make its way into your Agent’s context and get read as a command rather than data. Your MCP Server is a perfect delivery mechanism for exactly that.
At Thales, we have also been working on our own MCP Server behind the scenes.
What does this mean for you? Imagine a world where you no longer have to log into a console to analyze where last week’s attack traffic came from. No more manually putting together a monthly executive presentation on the state of your security posture.
The Thales Imperva MCP Server for Cloud WAF is in beta today, and for now, it’s read-only by design. Your agent can query, analyze and report across your estate. Need to see which sites have your “Block requests from South Africa” ACL policy enabled? Or what security rules are enabled for your production site? Just ask your Agent! No prior knowledge strictly necessary.
It’s open source and available on GitHub – pull the container, add your API credentials, and point your agent at it.
Having trouble remembering regex for your custom rules? Or finding yourself constantly making individual site changes? Tell us! Beta feedback is what shapes where this goes.
What is MCP server security?
MCP server security is the set of controls that protect a Model Context Protocol server — and the AI agent calling it — from abuse. Because a remote MCP server is an authenticated HTTP endpoint that exposes tools capable of real actions, it needs the same protections as any production API, plus AI-specific guardrails on the prompts and tool responses flowing through it.
What are the main MCP server security risks?
The recurring ones are prompt injection delivered through tool responses rather than user input, tool poisoning, over-broad OAuth scopes and token passthrough, session hijacking, SSRF during metadata discovery, the confused deputy problem in MCP proxy servers, and ordinary application flaws such as the command-injection RCE found in the Framelink Figma MCP server. Excessive tool permissions amplify all of them.
Are local MCP servers safer than remote ones?
They carry a different risk profile, not a smaller one. A local MCP server talking to the agent over stdio never touches the network, so the exposure is credentials in a config file and how far that server can reach on your behalf. A remote MCP server served over HTTP is Internet-facing, which makes it probeable — and also makes it something you can put network and API controls in front of.
Can a WAF protect an MCP server?
Yes, for the endpoint layer. Once an MCP server is remote it is an HTTP API, so a WAF and bot protection stop automated probing and injection-class attacks before they reach it, and API security covers schema abuse and business-logic attacks on its endpoints. What a WAF cannot do alone is judge intent inside the model workflow — that needs AI guardrails inspecting prompts and tool responses.
What are MCP server security best practices?
Treat the server as a production API: authenticate every inbound request and never accept tokens that were not issued for your server, use least-privilege scopes and non-deterministic session IDs bound to the user, validate and allowlist outbound URLs, start read-only before enabling write operations, log every tool call, and inspect tool responses as untrusted input. OWASP’s secure MCP development guide and the MCP specification’s security best practices are the reference baselines.
MCP is now an open standard under the Linux Foundation, and the number of exposed servers is only going up. The controls are the ones you already know — web application and API protection in front of the endpoint, API security on its schemas and business logic, and AI application security on the prompts and tool responses moving through it. See how Thales Imperva secures applications and APIs, and try the read-only Cloud WAF MCP Server beta on GitHub.
The post MCP Server Security: The Blind Spot in Your AI Stack appeared first on Blog.
Many Australian businesses have moved their applications and data to cloud-native architectures for agility, scalability, and sovereignty. However, this move extends their attack surface beyond their typical security boundaries.
As evidenced by the Thales 2026 Data Threat Report, attackers increasingly target web applications and APIs with sophisticated methods that outpace the traditional protection built into cloud platforms. Security teams face intense pressure to deliver control and risk reduction, but this mandate creates frustration with DevOps teams, who push for speed and scale while leveraging the benefits of cloud-native tools.
The gap is best addressed by bringing the Thales enterprise-grade Imperva Web Application and API Protection (WAAP) solution directly into Australia’s Google Cloud infrastructure through a native integration. For Australian organisations running critical workloads in Google Cloud, this creates some important opportunities.
Organisations need confidence in where their data is stored, how it is processed, and who can access it.
For operators of critical infrastructure, the data itself is strategically significant. Data such ass traffic patterns, transaction flows, and operational telemetry from energy, financial, and health systems can reveal how essential services function, where dependencies lie, and how disruptions might be engineered. Losing visibility and control over where that data is processed and who can access it is a different order of risk. For businesses subject to SOCI Act, APRA CPS 234, or other government security mandates, controlling where data is stored and how it travels is essential for complying with Australian data sovereignty requirements.
Security controls should not become a performance bottleneck. The conflict is tangible
While security teams want to ensure applications and APIs are protected with consistent security controls, visibility, compliance, and governance, DevSecOps teams want security that can be deployed quickly and integrated seamlessly into existing development workflows without creating operational overhead or slowing down application delivery.
This is one of the key reasons many organisations are showing strong interest in CI/CD-based onboarding models. Security teams prefer having the ability to deploy security controls without changing DNS records, modifying application architectures, or handing operational control of applications to another team or third-party provider.
A focus on websites is no longer enough for modern applications, as they depend on APIs, automation, third-party services, and machine-to-machine interactions that happen out of view of conventional monitoring. The threat actors understand this dependency and focus on the interfaces that run today’s digital services.
That is why WAAP has become such an important security category. Organisations need protection that addresses web application attacks, API abuse, automated bot activity, and Layer 7 denial-of-service attacks within a single security approach.
Imperva for Google Cloud delivers the same Imperva capabilities available through the broader cloud service, including Web Application Firewall (WAF) for cloud applications, API security, bot management, Layer 7 DDoS protection, and threat intelligence informed by global attack activity.
This is not a pared-down instance; Imperva for Google Cloud delivers the full WAAP stack locally, feature-for-feature, with the global service.
Pressure on security teams to cut complexity is high. According to the Thales 2026 Data Threat Report, companies use 7 distinct data protection and monitoring solutions, yet visibility, staffing, and complexity remain major concerns for security teams.
As Imperva WAAP now operates within Google Cloud Australia, it makes perfect sense for solutions such as Google Cloud Load Balancing, Google Kubernetes Engine (GKE), Compute Engine, and other networking tools to work together with API security.
For cloud and platform teams, security can be deployed alongside applications rather than treated as a separate environment that requires its own operational model.
One of the reasons organisations move to cloud platforms is the ability to scale up or down. Security infrastructure should be able to do the same.
Regardless of whether a business is dealing with seasonal demand challenges, big public-facing platforms, high-volume APIs, or expanding digital services, the security layer must evolve with the applications and not require continuous redesign.
As more Australian organisations build cloud-native services, that expectation will become standard.
Organisations increasingly want security controls that operate where their applications operate. For businesses building on Google Cloud, keeping workloads within Australia is becoming a practical architectural decision rather than a future aspiration. By unifying Imperva’s proven application security leadership with Google Cloud’s high-performance infrastructure, organisations can eliminate the need to compromise between security and speed.
Get in contact with the local team and see how Imperva WAAP works in Google Cloud Australia.
The post Google Australia Customers Now Benefit From Imperva Cloud-Native WAAP Security appeared first on Blog.
How Thales is bringing active API protection to self-managed environments, without compromising digital sovereignty.
Organizations have invested heavily in discovering APIs, classifying sensitive data, and understanding API risk. That’s progress.
But visibility alone doesn’t stop attacks.
Attackers don’t wait for analysts to review dashboards. They exploit broken authorization, enumerate objects, abuse business logic, and exfiltrate data in minutes.
Knowing an attack happened is useful.
Stopping it is what matters.
For organizations operating in finance, government, healthcare, defense, and critical infrastructure, API security has always carried another requirement.
Data cannot leave the environment.
API payloads often contain customer records, financial information, healthcare data, or classified information. Regulations and increasingly internal governance policies require that this information stays under organizational control.
That’s why many organizations choose self-managed API security.
Not because they dislike cloud. Because they cannot compromise sovereignty.
Digital sovereignty means retaining control over where sensitive data is processed, where security decisions are made, and who ultimately governs the infrastructure, protecting critical services.
That’s why Thales’s Self-Managed Imperva API Security was built, to give organizations the flexibility to deploy API security wherever their business, operational, or regulatory requirements demand, while keeping sensitive inspection and enforcement under their control.
Yet sovereignty has historically introduced an unintended compromise.
Historically, this created an operational gap.
Security teams could discover APIs.
They could identify risky endpoints.
They could detect sophisticated attacks such as Broken Object Level Authorization (BOLA), one of the most critical risks identified in the OWASP API Security Top 10.
But detection alone doesn’t interrupt an attack.
When enforcement exists outside the API security workflow, response becomes another investigation, another ticket, another operational handoff. Every delay gives attackers more time to exploit vulnerable APIs and access sensitive information.
Security teams weren’t lacking visibility.
They were lacking immediate action.
For organizations operating entirely within sovereign environments, this challenge was even greater. Protecting sensitive data meant keeping security operations local—but that shouldn’t mean sacrificing the ability to actively stop attacks.
Modern security should never force organizations to choose between operational control and effective protection.
This isn’t simply feature parity. It’s an architectural parity.
Detection and enforcement can now operate together where the data already resides.
Today, that trade-off disappeared.
With the latest enhancement to Thales’ Self-Managed Imperva API Security, organizations can now extend active API enforcement into self-managed deployments while maintaining complete control over where inspection, detection, and enforcement take place.
This is more than a new capability.
It represents an important step toward a sovereign-by-design security architecture—one where security adapts to the customer’s operational model instead of requiring the customer to adapt to the security platform.
Organizations no longer have to choose between maintaining sovereign control over sensitive API traffic and deploying modern API protection capable of responding to attacks in real time.
Detection and enforcement now work together, exactly where the data already resides.
Modern enterprises rarely operate in a single environment.
Applications span public cloud, private cloud, Kubernetes clusters, on-premises data centers, and increasingly hybrid infrastructures.
Security shouldn’t become fragmented simply because deployments are.
Whether organizations deploy Imperva API Security through a cloud-managed service or a self-managed environment, they should expect the same security intelligence, consistent policy model, and comparable protection outcomes.
The deployment model changes.
The protection model doesn’t.
For organizations embracing digital sovereignty, that’s an important distinction. They can adopt the architecture that best aligns with their regulatory obligations and operational requirements while maintaining a consistent security posture across every environment.
The future of cybersecurity isn’t simply about moving more workloads to the cloud.
It’s about giving organizations the freedom to choose where their data lives, where security operates, and how trust is established.
That is the essence of digital sovereignty.
Modern security platforms must deliver the same level of protection regardless of deployment model, enabling organizations to protect critical assets without compromising regulatory compliance, operational resilience, or customer trust.
API security should be no exception.
With Self-Managed Imperva API Security enforcement, organizations can now:
Digital sovereignty is no longer simply a regulatory discussion.
It’s becoming a defining principle of modern cybersecurity architecture.
As organizations continue to modernize applications, embrace AI, and expand digital services, they need security platforms that protect innovation without requiring sensitive data to leave their control.
That’s the direction Thales has long championed: security that enables trust, resilience, and customer choice.
The latest Self-Managed Imperva API Security enhancement is another step toward that vision, bringing active API protection to organizations that require complete operational control, without compromising the security outcomes they expect.
Because the future of API security won’t be defined by where it runs.
It will be defined by where trust resides.
And increasingly, trust begins with keeping control of exactly where it belongs.
Download this guide to discover how Imperva protects production APIs without compromising data sovereignty.
The post Closing the Sovereignty Gap: Bringing Active API Protection to Self-Managed Environments appeared first on Blog.
The internet is changing fast.
For years, the main goal of search was simple: to help users find links. A user searched, reviewed results, clicked a website, and consumed the content directly from the source.
But AI is changing that model. Increasingly, users ask AI assistants for answers instead of searching for websites. They seek summaries, recommendations, comparisons, troubleshooting advice and product guidance, often receiving a complete answer without ever visiting the original source site. This creates a new reality for website owners: your content may still influence the customer journey, even when the customer never reaches your website.
This shift is why AI bot traffic matters.
AI bots scan, fetch, and process web content so AI systems can answer questions, summarize pages, recommend vendors, and understand what your business does. Some of this traffic creates value. Some of it can create risk. The challenge is knowing the difference and building the right policy.
Quick answer: Not all AI bots should be treated the same. AI traffic falls into four main types: AI search bots that help your brand appear in AI answers, AI training bots that collect content to train models, AI fetch bots that retrieve a page on behalf of a user, and agentic AI systems that take actions such as logging in, querying inventory, or completing transactions. The right policy is not “allow all” or “block all”; it is to classify each AI bot, decide which to allow on which parts of your site, and inspect every request for malicious behavior. Imperva Advanced Bot Protection classifies AI traffic, while Imperva Web Application Firewall and DDoS Protection inspect and rate-limit it, so you stay visible to trusted AI while blocking abuse.
As the risk from AI-driven bots increases, many organizations are now facing a difficult question:
Should we allow AI bots to scan our website, or should we block them?
Blocking all AI bots may seem like the safest option, but it can also reduce your visibility in AI-generated experiences. If your public content is not accessible to the right AI systems, your brand may appear less often when users ask AI tools for recommendations or information.
On the other hand, allowing every AI bot creates business and security risks. AI bots may collect valuable content, increase traffic costs, overload servers, or access areas of the website that were never meant to be used by automated systems.
So, the right question is not “allow or block AI bots?”
The better question is:
The Rise of Agentic AI
The next wave of AI traffic will not come from crawlers alone. It will come from autonomous AI agents acting on behalf of users.
Agentic AI systems can browse websites, compare products, gather information, interact with APIs, complete forms, and execute multi-step workflows with limited human intervention.
Unlike traditional search crawlers, these agents actively interact with business logic. They can create accounts, query inventory, test workflows, retrieve pricing, and trigger application functions.
This creates a new challenge for security teams. The question is no longer simply whether an AI bot is legitimate. The question is whether the action being performed should be allowed.
As AI agents become more capable, organizations need controls that evaluate identity, intent, behavior, and access permissions simultaneously.
Imperva Advanced Bot Protection provides one of the industry’s most comprehensive AI traffic classification capabilities, enabling organizations to identify AI search bots, AI training bots, AI fetch bots, and emerging agentic AI systems. Security teams can then apply granular policies to allow, restrict, rate-limit, or block AI traffic based on business risk and application context.
As AI traffic becomes more diverse, organizations need visibility not only into which AI tools are accessing their applications, but also what those tools are doing, which business functions they are interacting with, and whether that activity aligns with organizational policy.
Effective control starts with understanding the different types of AI traffic and applying policies accordingly.
To create a good policy, you first need to understand the different types of AI bots.
AI search bots scan public websites so AI-powered search engines and answer engines can understand what content exists online.
These bots may help your business stay visible when users ask AI tools questions like “What is the best solution for…?” or “Which vendor supports…?”
You may want to allow these bots on public marketing pages, blogs, product pages, and documentation — especially content you want customers to discover.
Training bots collect public web content that may be used to train or improve AI models.
This is where the discussion becomes more nuanced. You may want your brand to appear in AI answers, but you may not want your full content, research, product information, or intellectual property used to train external models without control or compensation.
For many organizations, training bots require a stricter policy than search bots.
AI fetch bots usually act in response to a user request. For example, a user asks an AI assistant to summarize a specific URL, check a product page, or compare information from your site.
Because these requests are typically initiated on behalf of a user, they often represent legitimate business value. However, they can also be abused. An attacker may try to manipulate an AI assistant into sending suspicious payloads, scanning pages, or probing your application while hiding behind a legitimate AI fetcher.
That means fetch bots should not automatically be trusted. They should be allowed only with the same security inspection applied to any other request.
AI is enabling attackers to create bots that learn from mitigation controls, adapt their tactics, and persistently probe applications in ways that were previously impractical at scale.
According to Imperva’s 2026 Bad Bot Report, the average number of AI-driven bot attacks has increased more than tenfold (12.5x) in 2025 compared to the previous year. This growth reflects a broader trend: the same technologies helping AI assistants understand websites can also help malicious actors understand application defenses, automate reconnaissance, and accelerate attack development.
Beyond increasing the scale and sophistication of bot attacks, AI is also lowering the barrier to entry for attackers. With the right prompts, common AI assistants can be weaponized to help identify weaknesses in web applications, generate attack payloads, automate vulnerability discovery, and assist with exploiting business logic flaws. While these tools have safeguards, they can still ramp up activities that traditionally required specialized security knowledge.
AI is also enabling attackers to coordinate large-scale campaigns more efficiently, combining reconnaissance, automation, and exploitation in ways that were previously more resource-intensive and time-consuming.
As a result, organizations must consider not only how AI systems access their applications, but also how AI may be used to automate, scale, and weaponize traditional web attacks.
Thales’s threat research data shows that legitimate AI bots currently account for around 2% of total session traffic. The Bad Bot Report shows that within that AI bot traffic, 85% comes from AI crawlers and 15% comes from AI fetch bots. While AI traffic remains a relatively small proportion of overall web traffic today, its growth rate and increasing sophistication suggest it will become a much larger consideration for application owners over the coming years.
This matters because even legitimate AI bots can introduce operational, security, and business risks.
The main risks are:
Data scraping: AI bots may continuously collect proprietary content, product data, documentation, or intellectual property.
Unintentional overload:: AI bots can be aggressive. High-speed crawling may consume bandwidth, slow the application for real users, and increase infrastructure costs.
Abuse through AI fetch bots: because fetch bots act on user prompts, attackers may try to manipulate them into sending malicious requests or scanning for weaknesses while appearing to come from a legitimate AI source.
The good news is that classic application attacks from legitimate AI bots remain relatively low. Imperva’s findings show low levels of traditional attack vectors such as SQL injection, cross-site scripting, illegal resource access, backdoor attempts, and remote file inclusion. However, there are still real examples where AI fetch bots were manipulated into sending malicious payloads, including SQL injection-style input.
This is exactly why AI bot policy should never be based only on identity. Even a legitimate AI bot must still be inspected for malicious behavior.
Visibility is only the first step. As AI traffic continues to grow, organizations need the ability to distinguish between beneficial AI activity and behavior that introduces operational, security, or business risk.
AI search bots, AI training bots, AI fetch bots, and agentic AI systems all require different treatment. The challenge is not simply identifying them. It is applying the right controls to the right AI traffic at the right time.
This is where advanced bot management becomes critical.
In our blog, Why AI Bot Protection and Control are Essential for Application Security, we said, “The ability to control which parts of your application functionality are accessible to AI tools is critical to your AI Security Strategy”.
The safest approach is a layered policy.
Start by separating the website into zones:
Public content you want AI systems to understand
Examples: blogs, product pages, public documentation, company information, support articles, and thought leadership.
Content you may want to restrict
Examples: premium content, customer-only portals, pricing logic, internal search, account pages, sensitive documentation, APIs, and dynamic application flows.
Content that should never be accessed by bots
Examples: admin paths, login actions, checkout abuse paths, personal data, private files, and application endpoints that can trigger expensive actions.
Then decide which AI bot categories should be allowed in each zone.
A practical policy could look like this:
| Bot type | Recommended approach |
| AI search bots | Allow on public content where visibility matters |
| AI training bots | Review carefully; block or limit where IP protection matters |
| AI fetch bots | Allow only with full security inspection and rate controls |
| Unknown AI bots | Treat as suspicious until verified |
| Aggressive crawlers | Rate-limit or block if they impact performance |
The goal is not to trust or distrust AI traffic. The goal is to understand it, classify it, and apply the appropriate controls. Thales helps organizations strike the right balance between AI visibility and application security by combining Imperva Advanced Bot Protection, Imperva Web Application Firewall, and Imperva DDoS Protection. Thales offers customers a number of different options for managing AI bot traffic without choosing between full exposure and full blocking.
Firstly, Thales’ core security protections, delivered through Imperva Web Application Firewall, inspect the request itself. Rules for SQL injection, cross-site scripting, illegal resource access, backdoors, and remote file inclusion do not depend only on who the client claims to be. If an AI bot is manipulated into sending a malicious request, Imperva WAF can still block that request out of the box.
Secondly, Imperva DDoS protection helps reduce the risk of aggressive AI crawling overwhelming the application or creating performance issues. This is important because even legitimate AI bots can generate high request volumes.
Thirdly, customers can choose their own policy. If they want to allow a specific AI bot, using Imperva Advanced Bot Protection, they can create an exception based on the bot’s Client App ID. If they want to block a specific AI bot completely, they can add it to a bad bots list in the Imperva portal.
Most importantly, even when a specific AI bot is excluded from bot protection rules, malicious requests from that bot are still inspected by Imperva’s core security rules. In other words, allowing an AI bot for visibility does not mean you are leaving your application unprotected.
Not usually. Blocking every AI bot can reduce your visibility in AI-generated answers and recommendations, while allowing all of them exposes you to scraping, infrastructure overload, and abuse. The safer approach is to classify AI bots and allow them selectively, by website zone, with security inspection applied to every request.
There are four: AI search bots (so AI answer engines can understand your public content), AI training bots (which collect content to train AI models), AI fetch bots (which retrieve a specific page on behalf of a user), and agentic AI systems (which take actions such as logging in, querying inventory, or completing transactions).
Agentic AI systems act on behalf of users, browsing sites, filling forms, querying APIs, and running multi-step workflows with limited human input. Because they interact directly with business logic, the key question shifts from “is this bot legitimate?” to “should this action be allowed?”
According to Imperva’s 2026 Bad Bot Report, automated traffic accounted for more than 53% of all web traffic in 2025. Legitimate AI bots are a small share of that today, around 2% of session traffic in Imperva’s threat-research data, but their volume and sophistication are growing quickly.
Usually, but not blindly. Fetch bots typically act on a real user’s request, so they often carry legitimate business value. However, they can be manipulated into sending malicious payloads, so they should be allowed only with the same security inspection applied to any other request.
To learn more visit https://www.imperva.com/products/ai-application-security/
The post AI Agents Are Visiting Your Website. Which Ones Should You Trust? appeared first on Blog.
Quick answer: No single tool secures an API. API security is a layered discipline. Secure-coding analyzers and SCA scanners catch code and dependency flaws; DAST tests running APIs; API gateways and IAM enforce authentication and rate limits; a WAF blocks known attack patterns; bot management stops automated abuse; and runtime API security adds continuous discovery and catches business-logic threats like BOLA that other tools miss. This guide maps these API security tools to seven risk domains so you can see your coverage—and your gaps.
APIs power mobile apps, partner integrations, cloud microservices, SaaS platforms, and AI services; they are the business.
According to Imperva’s State of API Security report, API traffic now accounts for over 71% of all web traffic. As APIs have exploded in number and importance, so has the challenge of securing them.
When organizations look for “API security,” they quickly face a confusing mix of tools:
Each tool does protect APIs, but only in its own narrow way.
API security is not a single product. It is an architectural discipline that spans the entire API lifecycle: from design to code, deployment, runtime, and monitoring.
This blog cuts through the noise. It shows exactly which risks each security component addresses, and where the gaps remain, so you can build a complete, layered defense.
API risks don’t come from one place. They appear at every stage of the software lifecycle. Here are the seven core risk domains you must understand:
Real breaches almost always happen when risks from multiple domains line up.
Example:
A valid token (authentication risk) + excessive data exposure (design risk) + an exposed endpoint (configuration risk) + automated enumeration (abuse risk) = a major breach.
No single tool covers every domain. That’s why a layered approach is essential.
Enterprise API protection never comes from one product. It’s a combination of tools working in different layers. Here’s what each major component does:
Here’s a clear, at-a-glance view of what each component covers:
| Security Component | Design | Code | Supply Chain | Config | Auth | Abuse | Logic |
| SAST | |
|
|
|
|
|
|
| SCA | |
|
|
|
|
|
|
| DAST | |
|
|
|
|
|
|
| WAF | |
|
|
|
|
|
|
| API Gateway | |
|
|
|
|
|
|
| IAM | |
|
|
|
|
|
|
| Bot Manager | |
|
|
|
|
|
|
| Runtime API Security | |
|
|
|
|
|
|
Legend
= Strong / primary coverage
= Partial or indirect coverage
= No meaningful coverage
What Runtime API Security delivers
Quick takeaway on Runtime API Security
It shines brightest in Business Logic (its real superpower) and gives helpful visibility across most other domains, but it still works best alongside the other tools. Solutions like Imperva API Security from Thales are built specifically for this layer.
Building Your Layered API Security Strategy
API security isn’t about buying one magic product. It’s about understanding the full risk picture and picking the right tool for each layer.
Next Steps
Organizations that treat API security as an architectural discipline, not a checkbox, are the ones that move fast and stay secure.
What tools are used for API security?
There is no single API security tool. A complete stack layers several: secure-coding analyzers (SAST) and software composition analysis (SCA) for code and dependency flaws, DAST for testing running APIs, API gateways and IAM for authentication and rate limiting, a WAF for known attack patterns, bot management for automated abuse, and runtime API security for discovery and business-logic threats such as BOLA.
Is a WAF enough to secure APIs?
No. A WAF blocks known attack patterns at the edge, but it cannot see business-logic abuse like Broken Object Level Authorization (BOLA) and does not discover shadow or undocumented APIs. Imperva’s research notes that traditional tools such as a WAF struggle to detect API business-logic abuse, so runtime API security is needed alongside it.
What is runtime API security?
Runtime API security continuously discovers every API—including shadow and deprecated endpoints—monitors live traffic, and uses behavioral analysis and object-level authorization checks to catch business-logic attacks, including the low-and-slow threats other tools miss.
What are the main API security risks?
API risk spans seven domains across the lifecycle: design and specification, code-level, third-party and supply chain, deployment and configuration, authentication and access, automation and abuse, and business logic and behavioral risks. Most breaches happen when risks from several domains line up at once.
The post API Security Demystified: Which Tools Actually Protect Your APIs (And Where the Gaps Are) appeared first on Blog.
Quick answer: On-premises API security keeps API discovery, detection, and enforcement inside your own perimeter instead of a third-party cloud—the model regulated industries need. Deploying it natively on Kubernetes (sidecar sensors → a discovery controller → an inline WAF gateway) makes it practical: continuous API discovery surfaces shadow and zombie endpoints, behavioral detection catches API-specific threats like BOLA, and the WAF blocks them in real time.
Most security teams already know they need API discovery, including east-west traffic between internal services. That conversation has largely won. The harder question is: where do you actually deploy your API security solution?
For organizations in regulated industries, such as banks, healthcare systems, defense contractors, the answer isn’t straightforward. Data sovereignty requirements, compliance mandates, and network restrictions often rule out cloud-hosted security services. Your APIs run on-prem, so your API security has to run there too.
I spent years in application security before moving into product management, and one pattern kept repeating. Security teams have traditionally relied on preproduction security scanning and testing, which works well for known endpoints but inherently misses runtime security abuses, the shadow APIs, the undocumented endpoints, the services that only reveal their risk under live traffic. The coverage gap wasn’t a technology problem it was a deployment problem. The security tooling wasn’t running where the APIs were running.
That’s the problem this article is about. Not whether you need API security, you do. But how and where you deploy it, so it covers your full environment and increasingly, the answer is Kubernetes.
Once you’ve decided to deploy on-prem, the first thing that becomes clear is just how much of your API footprint was previously unaccounted for.
In my experience working with customers, teams often start out believing they have around 50 or 60 API endpoints. Once automated discovery runs against live traffic, that number frequently jumps to 300+. It’s not that anything was done wrong — those extra 240+ endpoints simply weren’t in any documentation or Swagger file. They were built for legitimate reasons, serving real traffic in production, but had never gone through a formal security review.
The real value of discovery is surfacing these blind spots not to assign blame, but to give security teams complete visibility so they can protect the full attack surface, not just the parts they already knew about.
When API security runs externally or as a periodic exercise, you’re dependent on someone compiling a list of endpoints before anything gets scanned. That’s not a people’s failure it’s an architectural one. The security tooling isn’t sitting where the traffic flows, so it can only see what it’s told about.
Engineers focus on what they’re actively building. The endpoint they created eight months ago for a partner POC that never went anywhere? It’s not on their radar. The internal debugging endpoint that was supposed to be temporary? Still running. The v1 of an API that was “replaced” by v2 but never actually decommissioned? Still accepting requests.
The security team scans what they’re given. The audit report comes back clean. And everyone moves on, not realizing that the scan only covers 30% of the actual attack surface.
WAFs are the enforcement backbone. They sit inline, they can block traffic, and they’re battle-tested. That’s exactly what you want to stop threats in real time. The challenge isn’t the WAF itself; it’s what the WAF knows about.
A WAF is incredibly effective when it knows what to look for and where to look. But traditional WAF deployments rely on rules and signatures of SQL injection patterns, XSS payloads, and malformed requests. API-specific threats like BOLA (Broken Object-Level Authorization) don’t match those patterns. An attacker changes an object’s ID to access someone else’s data, and the request looks perfectly normal. Well-formed, authenticated, and syntactically valid. The WAF has no reason to flag it because it doesn’t have the API-level context to know that request shouldn’t be accessing that resource.
That’s where a dedicated API security layer becomes the WAF’s force multiplier. It provides the discovery, the behavioral analysis, and the API-specific threat intelligence. The WAF provides inline enforcement. Together, they form a closed loop: the API security platform detects, the WAF gateway blocks. Neither is complete without the other.
And both can only protect what they can see, which brings us back to why continuous API discovery matters so much. If an endpoint was never registered and never put behind the WAF, it’s completely exposed. Discovery closes that gap.
This used to be a “nice to have” conversation. It’s not anymore. PCI DSS 4.0.1 now requires continuous API security testing and maintained API inventories. (These PCI DSS 4.0.1 requirements became mandatory on March 31, 2025.) The EU Cyber Resilience Act mandates security testing throughout the development lifecycle. ISO 27001:2022 introduced new application-security controls—including secure coding (A.8.28) and application security requirements (A.8.26)—that apply directly to APIs. If you’re in a regulated industry running on-prem APIs and you don’t have dedicated API security, your next audit is going to be uncomfortable.
Modern application environments are increasingly standardizing Kubernetes. It’s where workloads run, where infrastructure teams are investing, and where operational tooling is already mature. Our on-prem API security solution is purpose-built to deploy natively on this infrastructure.
Because it runs on Kubernetes, it inherits the operational benefits that teams already rely on pod-level self-healing for high availability, Helm-based deployments for consistent upgrades, and native integration with existing monitoring stacks like Prometheus, Grafana, or the ELK stack. There’s no separate HA architecture to build, no custom upgrade orchestration to maintain, and no new observability tooling for your SREs to learn.
For teams already running Kubernetes, adding API security to the cluster is operationally familiar. It fits into the workflows, tooling, and processes your infrastructure team already uses every day
Here’s how architecture works in practice.
API discovery works through our lightweight sensors, deployed as Kubernetes sidecars alongside your application pods. These sensors passively mirror API traffic without adding latency or altering request flows and send the metadata to the API Security controller. The controller analyzes this traffic and continuously builds a complete inventory of every API endpoint in your environment, including REST, GraphQL, gRPC, and SOAP.
Because discovery is based on live traffic observation through the sensors rather than static documentation or manual reporting, it surfaces everything shadow APIs that were never documented, zombie endpoints that were supposed to be decommissioned, and internal services that no one remembered to put through a security review.
In my experience working with customers, teams that expected 50 or 60 endpoints routinely discover 300+. The discovery phase alone just seeing what you actually have justified the deployment for a lot of organizations. It’s the difference between securing a fraction of your attack surface and securing all of it.
Not every API carries the same risk. A health-check endpoint and a payment processing API are in different universes from a security standpoint. The platform classifies APIs based on what data they handle PII, financial data, credentials, health records and assigns risk scores. This is what keeps security teams from drowning in alerts. You focus on the endpoints that matter most.
The API security platform builds behavioral baselines for API usage and flags deviations. BOLA patterns. Schema violations. Unusual request volumes. Credential stuffing. Authentication anomalies. This is the intelligence layer it understands API-specific threats that signature-based rules alone can’t catch. But intelligence without enforcement is just expensive monitoring. That’s where the WAF gateway comes in.
This is where our solution stands apart. The API security controller detects threats. The WAF gateway enforces inline. It’s a closed loop detection that intelligence feeds directly to the gateway, and the gateway blocks in real time. Neither layer is effective alone. The controller without the gateway can only be alert. The gateway without the controller only has signatures and static rules to work with. Together, you get detection depth and enforcement power.
We are the only solution on the market capable of this level of fine-grained blocking. And by fine-grained, we mean something very specific.
Most competing approaches block at the IP level attacker identified; entire IP blocked. In any real environment, API consumers share IPs constantly. Corporate NAT gateways, CDN exit nodes, partner integrations behind shared proxies. Block one IP and you cut off every legitimate consumer behind that address.
Our enforcement goes well beyond endpoint-level blocking. When the controller detects a threat to say, a BOLA attack doesn’t just block the endpoint or the source IP. It pushes a targeted rule to the WAF gateway that blocks the specific request pattern and the specific token involved. That means a malicious actor session gets shut down while other users hitting the same endpoint from the same IP continue uninterrupted. The blocking is surgical scoped to the exact behavior and identity, not the network address or even the endpoint as a whole.
This might sound like a subtle technical distinction, but in production it changes everything. It’s the difference between a security tool your operations team is confident turning on and one they keep in monitor-only mode because they’re afraid of the blast radius.
I’m framing these as actual conversations because that’s how they come up in practice.
“We don’t know how many APIs we have.” This is the most common starting point, and continuous discovery closes the gap immediately. Every endpoint serving traffic gets catalogued and classified, whether it’s in your documentation or not.
“Our WAF handles API security.” Your WAF is the enforcement engine, and that’s exactly the role it should play. What it needs is the right intelligence to feed it. A dedicated API security layer provides continuous discovery, behavioral analysis, and API-specific threat detection and routes that intelligence to your WAF gateway for inline blocking. Think of it as upgrading your WAF’s awareness, not replacing it.
“We can’t send traffic to a third-party cloud.” Then don’t. On-prem deployment keeps everything in traffic analysis, detection, enforcement, and reporting inside your perimeter. This is usually a non-negotiable requirement, not a preference for organizations in regulated industries.
“We need to prove compliance and we’re running out of time.” Continuous monitoring produces always-current audit evidence. API inventories, risk classifications, threat logs, and remediation records. It replaces the scramble of point-in-time assessments. I’ve watched teams go from dreading audits to walking in with dashboards. It changes the dynamic completely.
“Dev ships new APIs every week. Security reviews quarterly.” That gap is where unprotected APIs live. Automated discovery closes it. New endpoints get monitored the moment they start serving traffic.
I want to spend a minute on this because there’s a perception that on-prem API security deployment is a multi-week project. In my experience, for teams that already have Kubernetes running, it’s measured in hours.
The typical flow:
Upgrades are the same model. Helm upgrade, new chart version, done.
For a detailed step-by-step installation walkthrough, refer to our deployment guide (available to Imperva customers)
The hard part isn’t deployment. It’s usually an organizational conversation about whether to do it in the first place. Once that decision is made, the technical execution is straightforward.
API-first architecture isn’t slowing down. If anything, the pace is accelerating in exactly the environments that have the strictest infrastructure constraints of financial services, healthcare, government, critical infrastructure. These organizations need API security that respects their boundaries, not one that asks them to relax those boundaries.
Kubernetes gives you the operational foundation. Purpose-built API security gives you visibility, detection, and enforcement. Together, they deliver a security posture that keeps up with how fast your team ships.
And it all runs inside your own perimeter. Which, for a lot of the teams I work with, is the only answer that matters.
Learn more about Thales’s Imperva unified API security platform.
API security has moved from “nice to have” to “audit requirement.” If your APIs run on-prem, your security needs to run there too. Kubernetes makes that operationally viable. The question isn’t whether to do it. It’s how soon.
On-premises API security runs API discovery, threat detection, and enforcement inside your own data center or private cloud instead of sending traffic to a third-party SaaS. It keeps all API traffic, logs, and analysis within your network perimeter—often a hard requirement for banks, healthcare, government, and other regulated organizations with data-sovereignty and compliance constraints.
Yes. A Kubernetes-native API security platform deploys as lightweight sidecar sensors next to your application pods, feeding mirrored traffic to a controller that builds a live API inventory across REST, GraphQL, gRPC, and SOAP. Because it runs on Kubernetes, it inherits pod-level high availability, Helm-based upgrades, and integration with monitoring stacks like Prometheus and Grafana—so adding it to an existing cluster typically takes hours, not weeks.
A shadow API is an endpoint serving live traffic that is not in any documentation, Swagger file, or official inventory—often an old version, partner integration, or internal debugging endpoint that was never decommissioned. Continuous, traffic-based API discovery surfaces shadow (and “zombie”) APIs so security teams can protect the full attack surface, not just the endpoints they already know about.
The post On-Premises API Security on Kubernetes: What It Actually Looks Like in Practice appeared first on Blog.
There is a moment every security analyst knows well. It’s 2am, an alert fires, and you’re staring at a console trying to make sense of what just happened—fast. You need context, scope, and impact: What’s being targeted? Where is it coming from? Is it getting worse? What should we do next?
That moment is exactly what we built the Imperva AI Assistant to improve, starting with Cloud WAF (cWAF) investigations, where speed and clarity matter most.
Modern application security environments generate a constant stream of signals across events, trends, attack patterns, and security posture. But turning that data into meaningful insight still takes effort. Analysts often move between dashboards, filter logs, and stitch together context across multiple tools to understand what’s happening.
At the same time, teams are expected to do more with less. A persistent skills gap and increasing alert volume mean even routine investigations can take longer than they should, slowing response times and adding pressure to already stretched teams.
The industry’s traditional response has been more dashboards, more saved reports, and more training. We think there’s a better answer: let your team ask the question in plain English and get a structured, security-relevant answer back immediately, grounded in Imperva platform data.
What is an AI security assistant?
An AI security assistant is a natural-language tool that lets security teams investigate threats by asking questions in plain English, instead of building queries or navigating dashboards, and returns fast, ranked, security-relevant answers grounded in their own platform data. The Imperva AI Assistant brings this capability directly into the Imperva platform, starting with Cloud WAF investigations.
Protect with AI: Making security work faster, simpler, and more accessible
To address this, we’re bringing the power of AI directly into Thales’s Imperva platform.
It builds on AI ExplAIn, the one-click, plain-language explanations we introduced for Imperva Cloud WAF, extending that same clarity from individual blocked requests to full, cross-product investigations.
Our goal is simple: help security teams get answers faster, reduce manual effort, and improve day-to-day productivity.
The AI Assistant is designed around three key goals:
Increase productivity
Instead of navigating dashboards or writing complex queries, users can simply ask a question and get an answer immediately.
Make AppSec more accessible
You don’t need deep expertise in Thales or Cloud WAF. The assistant uses natural language, making it easier for more team members to investigate and understand security data.
Support a wide range of use cases
Security questions don’t follow a fixed script. Our assistant can handle a variety of queries, from investigations to trend analysis, without requiring predefined workflows.
Instead of being limited to predefined dashboards or reports, teams can explore questions as they arise, using plain language to surface insights that would be impractical to design into a traditional UI. Because the assistant can draw on signals across the Imperva AppSec platform, it doesn’t just retrieve data – it connects it.
For example, an analyst might ask: “Was the IP that triggered a WAF block also behaving like automated traffic in the same session, and what changed compared to previous activity?”, and get a clear, unified answer in seconds, without having to pivot across tools or manually stitch the data together.
Security investigations, simplified with an AI security assistant
The AI Assistant is a natural-language experience built into the Imperva platform to help security teams investigate faster.
Instead of navigating dashboards or building filters, teams can simply ask:
The assistant responds with a concise, ranked answer, along with a Critical Finding that highlights the security -relevant insight, not just raw data. The assistant can also access all Imperva documentation, so teams can ask “How do I configure…? Or “Where can I find…?” to easily find the information they need.
A real-world investigation, simplified.
Imagine a security analyst investigating a sudden spike in application traffic.
Today, that process often involves switching between dashboards, filtering logs, and piecing together data from multiple sources to understand what’s happening.
With the AI Assistant, the workflow is much simpler.
The analyst can ask:
Within seconds, the assistant provides a clear, summarized answer, highlighting key trends, identifying the most relevant signals, and surfacing a Critical Finding that explains what matters. Instead of manually connecting the dots, the analyst can quickly understand the situation, prioritize next steps, and respond faster.
When investigating potential threats, teams need more than confirmation that “something triggered.” They need fast, clear answers that help them understand what’s happening and what to do next.
The AI Assistant is designed to answer these questions directly, reducing investigation friction and helping teams move from data to insight, faster.
In practice, this means security teams can move from alert to understanding faster—without adding complexity or changing existing workflows.
The AI Assistant is built directly into the Imperva AppSec platform, there’s nothing new to install or manage.
It’s available through the Ask AI experience and works within your existing environment, using the same data, workflows, and permissions you already rely on.
Because it’s permission-aware by design, users only see the data they’re authorized to access.
AI capabilities are always optional, customers can choose whether to enable or disable them at any time, ensuring full control over how AI is used in their environment.
The AI Assistant is currently available under controlled availability for a select group of customers. This phase allows us to refine quality, guardrails, and workflows based on real-world feedback before broader rollout.
AI in security has been discussed for years, often focused on detection and tuning. But the real pressure point has always been the moment of investigation, when teams need to quickly understand what’s happening and decide what to do next.
That’s where the AI Assistant is different. It focuses on turning security data into clear, actionable insight – faster. It doesn’t replace expertise, but it makes effective investigation workflows easier to access across the team.
When fewer people are bottlenecks for interpreting signals, response times improve, escalations reduce, and teams spend less time on repetitive analysis.
The impact is simple: faster decisions, fewer handoffs, and more time spent on the issues that matter most.
Security investigations get faster when teams can turn security data into explanations they trust. The Imperva AI Assistant is designed to shorten the path from alert to decision, starting with Cloud WAF, by helping analysts quickly pull the right data, spot what’s changed, and decide what to do next.
It starts with a question, and an answer you can defend.
What is an AI security assistant?
An AI security assistant is a natural-language interface that lets security teams ask questions in plain English and get fast, ranked, security-relevant answers drawn from their own platform data, instead of manually building queries or pivoting across dashboards. The Imperva AI Assistant delivers this inside the Imperva platform, starting with Cloud WAF investigations.
How is the Imperva AI Assistant different from AI ExplAIn?
AI ExplAIn gives one-click, plain-language explanations of individual blocked requests in Cloud WAF. The AI Assistant goes further, answering open-ended investigation and trend questions across the Imperva AppSec platform and connecting signals, such as a WAF block and automated-traffic activity, within the same session.
What questions can the AI Assistant answer?
Teams can ask investigative and trend questions such as “What are the top attack source IPs over the last 48 hours?” or “What changed between yesterday’s baseline and today’s spike?” Because it can also read the Imperva documentation, analysts can get configuration and “how do I…” answers in the same place.
Will an AI security assistant replace SOC analysts?
No. The AI Assistant is designed to speed up investigations, not replace expertise. It removes the manual work of pulling and correlating data so analysts can focus on judgment, prioritization, and response.
Is the data the AI Assistant sees kept private and under our control?
Yes. The assistant is permission-aware, so users only see data they are authorized to access, and AI capabilities are optional; customers can enable or disable them at any time.
Want to see it in action? Request a demo or ask your Thales team about the controlled availability process.
The post Your Security Operations Team Just Got Faster: Meet Imperva’s AI Assistant. appeared first on Blog.
The major enterprise WAAP solutions evaluated in this guide are Akamai, Cloudflare, F5, Fastly, Fortinet, Imperva, and Radware. In the most recent independent benchmarks, Akamai, Cloudflare, and Imperva were named Leaders in the Forrester Wave: Web Application Firewall Solutions, Q1 2025, while Akamai, Fortinet, and Imperva placed in the Leader category of the AMTSO-certified SecureIQLab Cloud WAAP v4.0 validation. The sections below compare these vendors on security efficacy, API protection, bot defense, operational efficiency, and total cost of ownership so you can match the right platform to your environment.
Web applications and APIs now sit at the center of nearly every digital business, and the threat surface has grown in step. Independent industry analysis estimates that API traffic represents more than 70% of all web traffic, that API related security incidents have climbed to roughly one third of reported data breaches, and that more than a third of recent API breaches trace back to Broken Object Level Authorization (BOLA) flaws.
At the same time, the latest AMTSO-certified SecureIQLab Cloud WAAP v4.0 validation found that average complete-security efficacy across the leading enterprise WAAP solutions declined year over year, even as operational efficiency improved slightly. The takeaway for security leaders is straightforward: WAAP capabilities are diverging across the market, and shortlist decisions made in 2022 or 2023 may no longer reflect current efficacy or operational fit.
This guide focuses on the major WAAP vendors that most frequently appear on enterprise shortlists. It draws on independent SecureIQLab testing, recent Forrester, Gartner, KuppingerCole, and IDC research, and verified peer reviews to help security and risk leaders evaluate platforms across modern, multi-cloud, API-heavy environments without reducing the decision to a generic ranked list.
This comparison focuses on the major WAAP vendors most commonly evaluated by enterprise buyers: Akamai, Cloudflare, F5, Fastly, Fortinet, and Radware, alongside Imperva. It uses three categories of independently sourced evidence:
Of the seven platforms covered here, four (Akamai, Cloudflare, Fortinet, and Imperva) completed the public SecureIQLab v4.0 cycle, while three of the competitors (F5, Fastly, and Radware) are listed in the SecureIQLab comparative report as “Contact SecureIQLab” rather than appearing with published v4.0 results. For those three vendors, the profiles below rely on Forrester, Gartner, and verified customer review sources, and head-to-head efficacy comparisons should be confirmed through buyer-led testing.
Other WAAP vendors (for example hyperscaler-native services and specialized API-security vendors) may be relevant for specific buyer needs, but they fall outside the major-vendor scope used here. Buyers should treat this guide as one input among several and validate every vendor claim against their own application portfolio during a proof of value.
Web Application and API Protection (WAAP) is a category defined by Gartner to describe cloud-delivered services that protect web applications and APIs against runtime attacks. Core capabilities typically include a Web Application Firewall (WAF), distributed denial-of-service (DDoS) protection, advanced bot management, API security, and increasingly client-side script protection.
In practical terms, a WAAP platform sits in front of an application (or a portfolio of applications and APIs) and inspects every request, blocking exploits aligned to the OWASP Top 10 and OWASP API Security Top 10, distinguishing legitimate users from automated abuse, absorbing volumetric and Layer 7 denial-of-service traffic, and providing the visibility security teams need to investigate and tune.
For a foundational explainer, see Imperva’s What is a WAAP? Learning Center article at imperva.com/learn/application-security/web-application-and-api-protection-waap/ (set as an internal link on publish).
Three forces are reshaping WAAP buying decisions in 2026:
For security leaders, the business outcomes a modern WAAP must support include reduced breach risk and downtime, faster time to protection for new applications and APIs, audit and compliance readiness, and predictable cost as application portfolios scale.
Use the table below to narrow the vendor set based on architectural focus and primary deployment use case. Then validate efficacy, API coverage, bot defense, and operational fit through your own proof of value. The order is alphabetical, not a ranking.
| Vendor | Primary architectural focus | Core deployment use case | Independent 2025 recognition |
| Akamai | Edge-delivered WAAP on a globally distributed CDN; integrated DDoS, WAF, bot, and API security. | Large enterprises and content-heavy properties needing edge scale and integrated bot defense. | Forrester Wave WAF Q1 2025 Leader; SecureIQLab v4.0 Leader category. |
| Cloudflare | Cloud-native WAAP delivered on a programmable global network; tightly integrated with Cloudflare CDN, DDoS, and developer platform. | Cloud-first organizations valuing developer experience, edge programmability, and rapid deployment. | Forrester Wave WAF Q1 2025 Leader; SecureIQLab v4.0 Visionary category. |
| F5 | Distributed Cloud WAAP combining BIG-IP Advanced WAF, Volterra, and Shape Security heritage. | Hybrid environments needing both ADC heritage and SaaS-delivered WAAP. | Forrester Wave WAF Q1 2025 Strong Performer; not published in SecureIQLab v4.0 public cycle. |
| Fastly | Edge-delivered WAF built on the Signal Sciences engine, integrated with Fastly’s programmable CDN. | Developer-led organizations prioritizing observability and integration into CI/CD workflows. | Forrester Wave WAF Q1 2025 Strong Performer; not published in SecureIQLab v4.0 public cycle. |
| Fortinet | FortiWeb WAAP available as VM, AMI, container, and SaaS, integrated with the Fortinet Security Fabric. | Fortinet-aligned shops consolidating network and application security under one fabric. | Forrester Wave WAF Q1 2025 Contender; SecureIQLab v4.0 Leader category. |
| Imperva (part of Thales) | Unified WAF, Advanced Bot Protection, API Security, DDoS, Client-Side Protection, and CDN, delivered as SaaS, on-premises, or natively inside AWS, Azure, and Google Cloud. | Enterprises needing unified, multi-cloud and hybrid WAAP with deep bot, API, and DDoS coverage, including cloud-native deployment. | Forrester Wave WAF Q1 2025 Leader; KuppingerCole 2025 WAAP Leader; SecureIQLab v4.0 Leader (Secure by Default). |
| Radware | Cloud Application Protection Service combining WAF, bot management, API protection, DDoS, and AI SOC. | Enterprises with significant DDoS exposure looking for an integrated suite plus AI-assisted SOC tooling. | Forrester Wave WAF Q1 2025 Strong Performer; not published in SecureIQLab v4.0 public cycle. |
Source: SecureIQLab 2025 Cloud WAAP CyberRisk Comparative Validation Report v4.0; Forrester Wave: Web Application Firewall Solutions, Q1 2025; Gartner Market Guide for Cloud WAAP; KuppingerCole 2025 Leadership Compass for WAAP. See references.
The Forrester Wave groups vendors into Leaders, Strong Performers, and Contenders, a single published designation that reflects the combined strength of each vendor’s current offering, strategy, and customer feedback. Rather than restate Forrester’s underlying sub-scores, the table below shows each covered vendor’s official tier, with a short note on what Forrester emphasized. This analyst recognition complements security-efficacy testing because it weighs roadmap, innovation, integrations, and customer feedback alongside current capabilities.
| Vendor | Forrester tier | What Forrester emphasized |
| Cloudflare | Leader | Strongest current offering of any vendor evaluated; efficiency-focused features; reference customers flagged support as an area to improve. |
| Akamai | Leader | Strong detection and automation; broad edge and DDoS scale; noted to lag in DevOps and scanning integrations. |
| Imperva | Leader | Standout Layer 7 DDoS, CISA Secure by Design Pledge signatory, and a unifying platform roadmap; room to improve in DevOps and scanning integrations and UI consistency. |
| F5 | Strong Performer | Built-in web application scanning and a strong API security story; fewer security operations integrations and a steeper learning curve. |
| Fastly | Strong Performer | Developer- and business-focused vision and pre-deployment rule testing; still building out API security. |
| Radware | Strong Performer | AI-assisted SOC tooling and tunable detection; fewer out-of-the-box integrations and less flexible reporting. |
| Fortinet | Contender | Strong API security capabilities and competitive pricing; roadmap less extensive than others, no rule versioning, and rule testing limited to logging mode. |
Source: Forrester Wave: Web Application Firewall Solutions, Q1 2025 (published tier designations and findings). Among the seven vendors covered here, three were named Leaders, three Strong Performers, and one a Contender.
A note on tier equivalence: within Forrester’s methodology, vendors positioned in the same tier hold equivalent standing in the evaluation. The three Leaders (Cloudflare, Akamai, and Imperva) are designated by Forrester as Leaders together; vendor-specific sub-criterion scores within the tier do not change the tier-level designation.
Independent customer ratings on G2 are a useful third complement to certified testing and analyst evaluation, because they reflect the day-to-day operational experience of paying customers. The table below shows the current G2 standing for each covered vendor’s flagship WAF product profile. Review-base sizes vary widely across vendors, so the rating is best read alongside the volume of reviews supporting it; vendors that have not actively claimed and managed their G2 product profile may show smaller review bases and older reviews.
| Vendor product (G2 profile) | G2 rating (of 5) | Review base | Notes |
| Imperva Web Application Firewall (WAF) | 4.7 | 41 | Highest G2 rating among the flagship WAF profiles of the seven covered vendors; primarily enterprise reviewers. |
| F5 BIG-IP Advanced WAF | 4.6 | 24 | Strong rating with a focused enterprise review base. |
| Radware Cloud WAF | 4.6 | 141 | Strong rating with the second-largest review base among the seven. |
| Cloudflare Application Security and Performance | 4.5 | 595 | Largest review base in the category overall; review mix skews toward small business segments. |
| FortiAppSec Cloud | 4.4 | 33 | Solid mid-market G2 standing; reflects Fortinet’s consolidated WAAP profile launched after the Forrester Wave Q1 2025 cutoff. |
| Fastly Next-Gen WAF | 4.2 | 30 | Solid mid-market rating; vendor profile noted on G2 as having limited features (managed but not upgraded). |
| Akamai App & API Protector | 4.0 | 2 | G2 explicitly notes that there are not enough reviews to provide buying insight; the product profile is unclaimed by the vendor. |
Source: G2 verified user reviews (most recent rating snapshots at time of writing). G2 product profiles do not always cover a vendor’s full WAAP suite, and review bases vary widely; the table compares each vendor’s flagship WAF product profile. See references.
Looking for the best WAAP solution?
Choosing the right WAAP platform depends on your organization’s unique security and operational needs. Contact our team to discuss your requirements and see how Imperva can help you achieve your application security goals. Get in touch with our team.
The framework below combines the SecureIQLab v4.0 evaluation model (security efficacy, operational efficiency, Secure by Design and Secure by Default ratings, false positive avoidance) with capability themes emphasized by Gartner and Forrester.
| Capability | What to evaluate |
| Security efficacy | Independently measured coverage of OWASP Top 10 (web), OWASP API Security Top 10 2023, and advanced threats including bots and Layer 7 DDoS. Look for AMTSO-certified results. |
| API and microservice protection | API discovery (including shadow and undocumented endpoints), schema enforcement, BOLA and broken authentication detection, support for REST, GraphQL, SOAP, WebSockets, and gRPC. |
| Bot and abuse mitigation | Ability to distinguish legitimate automation from malicious bots, behavioral analytics, device and TLS fingerprinting, defenses against account takeover, scraping, and inventory hoarding. |
| Runtime and cloud integration | Support for major public clouds, native in-cloud deployment, Kubernetes and service-mesh ingress, edge versus centralized models, multi-cloud and hybrid coverage, CI/CD integration. |
| Operational efficiency and FP avoidance | Time to protection, tuning effort, automation, analytics, and false positive avoidance under real traffic. In the latest SecureIQLab v4.0 cycle, false positive avoidance ranged from near-perfect at the top of the group to noticeably weaker at the bottom. |
| Performance and reliability | Latency impact, scalability under load, behavior of failure modes (fail-open vs fail-closed), out-of-path versus inline architecture, published service-level commitments for availability and mitigation time. |
| TCO and commercial fit | Licensing model (per app, per request, per Mbps), predictability under traffic spikes, alignment with portfolio growth, marketplace availability, integration with existing security and developer toolchains. |
| Ecosystem and roadmap | Vendor stability, innovation pace, AI assistance, hyperscaler partnerships, SIEM and SOAR integrations, partner ecosystem, support quality reflected in verified customer reviews. |
Use these five questions as a lightweight evaluation framework. Each maps to one or more of the capability themes above.
Look beyond generic OWASP coverage claims. Ask for AMTSO-certified third-party test results, and verify both web (OWASP Top 10) and API (OWASP API Security Top 10 2023) efficacy. In the latest SecureIQLab v4.0 testing, complete-security results spanned an extremely wide range, from near-complete coverage at the top to less than half of attacks blocked at the bottom, so the spread within a single shortlist can be very large.
APIs are no longer just REST. SecureIQLab v4.0 testing measured coverage separately across REST, GraphQL, SOAP, WebSockets, and gRPC, and found that coverage varied widely by protocol even within a single vendor, with WebSockets generally the weakest area across the group. Confirm vendor coverage protocol by protocol, not just by headline API score.
Ask vendors how they detect headless browsers, residential proxy traffic, and AI-driven scraping, and how those decisions are made without harming legitimate traffic. In the SecureIQLab bot suite, only a small number of the tested vendors blocked every attack type, so perfect bot defense is a genuine differentiator rather than a baseline.
Operational efficiency and false positive avoidance are tightly linked. In the latest cycle, the strongest vendors avoided essentially all false positives, while the weakest let through enough to translate into meaningfully more alerts per day and substantially more tuning effort for security operations teams. A few points of difference here can mean a very different daily workload.
Native in-cloud deployment, edge delivery, and traditional reverse-proxy models produce very different latency, resilience, and onboarding profiles, and per-request, per-Mbps, and per-application licensing produce very different cost curves as traffic scales. Walk through a 24 to 36 month projection with each shortlisted vendor, ideally informed by your own traffic baseline.
Each vendor profile below uses the same schema: a neutral summary, a list of capabilities verified from public documentation and independent sources, and a “Consider when” statement. Profiles are presented alphabetically. Capabilities should be re-validated against your specific environment during a proof of value.
Current market status: Publicly traded (NASDAQ: AKAM). Recognized as a Leader in the Forrester Wave: Web Application Firewall Solutions, Q1 2025, and placed in the Leader category of the SecureIQLab 2025 Cloud WAAP v4.0 validation.
Akamai delivers WAAP from one of the world’s largest edge networks, combining WAF, DDoS, bot management, API security, and client-side controls in its App & API Protector product. In SecureIQLab v4.0, the tested cloud-based deployment was among the strongest in the group on both complete security and operational efficiency, comfortably above the group averages, and avoided essentially all false positives. In the Forrester Wave Q1 2025, Akamai was named a Leader, strong on both current offering and strategy, with reference customers citing strong detection and automation; Forrester noted that Akamai lags in DevOps and scanning integrations and that some prospects weigh its pricing carefully.
Consider Akamai when your organization needs edge-delivered protection at very large scale, has significant CDN and DDoS requirements alongside WAAP, and wants a vendor with an established global footprint and analyst-recognized leadership.
Current market status: Publicly traded (NYSE: NET). Recognized as a Leader in the Forrester Wave: Web Application Firewall Solutions, Q1 2025, with the strongest current-offering position of any vendor evaluated. Placed in the Visionary category of the SecureIQLab 2025 Cloud WAAP v4.0 validation; rated Secure by Default.
Cloudflare delivers WAAP from a globally distributed programmable network, with strong developer experience, rapid feature velocity, and integrated DDoS, bot management, API gateway, and Page Shield (client-side protection). In SecureIQLab v4.0, Cloudflare’s complete-security result landed around the group average, but it blocked every bot and Layer 7 DoS attack type and avoided nearly all false positives; API coverage was uneven, with strength in SOAP and gRPC and notable weakness in REST and WebSockets in the tested configuration. In the Forrester Wave Q1 2025, Cloudflare was named a Leader and posted the strongest current offering of any vendor evaluated; Forrester credited an efficiency-focused feature set and noted that reference customers flagged customer support as an area to improve.
Consider Cloudflare when your organization values developer-led security, rapid time to deploy, and a unified edge platform across CDN, DDoS, and application protection. Plan to validate API coverage by protocol against your specific traffic mix during a proof of value.
Current market status: Publicly traded (NASDAQ: FFIV). Named a Strong Performer in the Forrester Wave: Web Application Firewall Solutions, Q1 2025. Not part of the public 2025 SecureIQLab v4.0 published cycle (listed as Contact SecureIQLab in the comparative report).
F5 brings deep WAF heritage from BIG-IP Advanced WAF and a multi-acquisition portfolio (Volterra, Shape Security), assembled into the Distributed Cloud (XC) WAAP service. F5 is often shortlisted by organizations with significant existing F5 application delivery and security investments and a need to span data center, multi-cloud, and SaaS-delivered WAAP. In the Forrester Wave Q1 2025, F5 was named a Strong Performer, solid on both current offering and strategy; Forrester credited built-in web application scanning (via its Heyhack acquisition) and a strong API security story, while noting fewer security operations integrations and a steep learning curve cited by reference customers. Because F5 did not appear in the public SecureIQLab v4.0 dataset, comparative efficacy claims should be validated through buyer-led testing.
Consider F5 when your environment already standardizes on F5 application delivery and security infrastructure, when hybrid (data center plus SaaS) WAAP is required, and when buyer-led testing can fill the absence of comparable public SecureIQLab v4.0 data.
Current market status: Publicly traded (NYSE: FSLY). Recognized as a Strong Performer in the Forrester Wave: Web Application Firewall Solutions, Q1 2025 (vision described by Forrester as developer- and business-focused). Not part of the public 2025 SecureIQLab v4.0 published cycle (listed as Contact SecureIQLab in the comparative report).
Fastly’s WAF is built on the Signal Sciences engine and is closely integrated with Fastly’s programmable edge platform. The product appeals to developer-led organizations that want deep observability into request decisions, the ability to test rules before deployment, and tight CI/CD integration. The absence of Fastly from the SecureIQLab v4.0 public cycle means head-to-head efficacy comparison against the 11 tested vendors must come from internal testing.
Consider Fastly when application security is closely coupled to a developer-first delivery culture, when observability and pre-deployment rule testing are priorities, and when the lack of public SecureIQLab v4.0 data can be supplemented by internal validation.
Current market status: Publicly traded (NASDAQ: FTNT). Named a Contender in the Forrester Wave: Web Application Firewall Solutions, Q1 2025, and placed in the Leader category of the SecureIQLab 2025 Cloud WAAP v4.0 validation.
FortiWeb is Fortinet’s WAAP, available as VM, AMI, container, and SaaS, and integrated with the broader Fortinet Security Fabric. The two independent sources frame Fortinet differently. In SecureIQLab v4.0, FortiWeb posted the strongest complete-security result among the tested platform vendors, with high operational efficiency and near-perfect false positive avoidance (its bot defense blocked three of the four attack types). In the Forrester Wave Q1 2025, Fortinet placed in the Contender tier, the only covered vendor below the Strong Performer band, with developing positions on both current offering and strategy. Forrester noted a roadmap less extensive than others in the evaluation, an absence of rule versioning, rule testing limited to logging mode, and limited compliance and performance reporting, while crediting strong API security capabilities and competitive pricing.
Consider FortiWeb when your organization is standardized on the Fortinet Security Fabric, when integrated network and application security is a priority, and when a competitively priced option within a large security platform is the goal. Buyers prioritizing rule lifecycle management (versioning, safe rule testing outside logging mode) or breadth of strategy and roadmap should weigh the Forrester findings and validate these areas during a proof of value.
Current market status: Now part of Thales (acquired December 2023). Recognized as a Leader in the Forrester Wave: Web Application Firewall Solutions, Q1 2025, and the KuppingerCole 2025 Leadership Compass for WAAP. Placed in the Leader category of the SecureIQLab 2025 Cloud WAAP v4.0 validation (the fourth consecutive cycle) and awarded the Secure by Default rating.
Imperva delivers a unified WAAP combining Cloud WAF, Advanced Bot Protection, API Security, DDoS Protection, Client-Side Protection, Account Takeover Protection, and CDN under one platform, available as SaaS, on-premises, or deployed natively inside hyperscale clouds. In SecureIQLab v4.0, Imperva was among the strongest in the group on both complete security and operational efficiency, well above the group averages, and notably achieved perfect 100% results in bot defense, Layer 7 DoS, and false positive avoidance, a combination of high efficacy and full false-positive discipline that few vendors matched. In the Forrester Wave Q1 2025, Imperva was named a Leader, strong on strategy and solid on current offering. Forrester highlighted Imperva’s Layer 7 DDoS, its signing of the CISA Secure by Design Pledge, and a roadmap that integrates its application security offerings into a unified platform, while noting room to improve in out-of-the-box DevOps and scanning integrations and in some UI consistency.
Consider Imperva when your organization needs unified WAAP across multi-cloud and hybrid environments, when deep API security and bot defense are required alongside core WAF and DDoS, when low operational burden and very high false-positive avoidance are priorities, and when cloud-native deployment inside AWS, Azure, or Google Cloud is on the roadmap.
Current market status: Publicly traded (NASDAQ: RDWR). Recognized as a Strong Performer in the Forrester Wave: Web Application Firewall Solutions, Q1 2025. Not part of the public 2025 SecureIQLab v4.0 published cycle (listed as Contact SecureIQLab in the comparative report).
Radware’s Cloud Application Protection Service combines WAF, bot management, API protection, and DDoS, with continued investment in AI-driven detection and SOC automation tooling. Radware’s heritage in DDoS protection makes it a frequent shortlist option for organizations whose risk profile is heavily weighted to availability attacks. In the Forrester Wave Q1 2025, Radware was named a Strong Performer, strong on strategy and solid on current offering; Forrester credited its AI SOC Xpert tool and tunable detection models, while noting fewer out-of-the-box integrations and reference-customer feedback that reporting could be more flexible. Comparable SecureIQLab v4.0 data is not publicly available for this cycle.
Consider Radware when DDoS exposure is a primary driver, when AI-assisted SOC tooling is valued, and when the absence of public SecureIQLab v4.0 data can be addressed through internal testing.
Imperva’s differentiation is grounded in four architectural realities that buyers can verify in their own environments and through independent testing.
No single platform is the right answer for every environment. Buyers whose dominant requirement is a single edge platform unifying CDN, application protection, and a developer-centric workflow, or whose primary driver is the deepest possible DDoS scrubbing capacity, will want to weigh those needs explicitly. The most reliable approach is to validate any shortlist, including Imperva, against your own threat model, traffic patterns, and cloud footprint during a proof of value.
Choosing a WAAP platform should start with your operating reality, not the vendor list. The matrix below maps the most common dominant security gap to the WAAP capabilities buyers should prioritize during evaluation.
| If your biggest gap is… | Prioritize… |
| API exposure and BOLA-style abuse | API discovery (including shadow APIs), schema enforcement, behavioral analytics, BOLA detection, broad protocol coverage (REST, GraphQL, SOAP, WebSockets, gRPC). |
| Bot abuse and account takeover | Behavioral bot detection, device and TLS fingerprinting, real-time risk scoring, integration with fraud and identity controls. |
| Volumetric and Layer 7 DDoS | Always-on DDoS scrubbing capacity, time-to-mitigate SLAs, AMTSO-validated Layer 7 DoS scores. |
| PCI DSS 4.0 client-side scripts | Client-side protection that inventories scripts, detects unauthorized modification, and produces auditable evidence. |
| Operational overhead and tuning effort | High Secure by Default scores, high independent false positive avoidance scores, automated policy generation, and analyst-recognized ease of management. |
| Multi-cloud, hybrid, and cloud-native coverage | Consistent policy and telemetry across AWS, Azure, GCP, and on-premises; native in-cloud deployment options; CDN-agnostic delivery; marketplace availability. |
| Developer-led delivery culture | CI/CD integration, infrastructure-as-code support, rule-testing tooling, programmable edge. |
There is no single best WAAP for every organization; the right platform depends on your threat profile, API footprint, and cloud architecture. Among the major vendors most often shortlisted by enterprises, Akamai, Cloudflare, and Imperva were named Leaders in the Forrester Wave: Web Application Firewall Solutions, Q1 2025, while Akamai, Fortinet, and Imperva placed in the Leader category of the AMTSO-certified SecureIQLab Cloud WAAP v4.0 validation. In that cycle, Imperva combined among the strongest security efficacy in the group with perfect 100% results in bot defense, Layer 7 DoS, and false positive avoidance. Validate any shortlist against your own traffic during a proof of value.
A Web Application Firewall (WAF) inspects and filters HTTP traffic to block common web exploits such as those in the OWASP Top 10. Web Application and API Protection (WAAP) is the broader, cloud-delivered category defined by Gartner that pairs a WAF with additional runtime defenses, typically DDoS protection, advanced bot management, API security, and client-side script protection. In other words, the WAF is one component inside a modern WAAP platform.
In the Forrester Wave: Web Application Firewall Solutions, Q1 2025, which evaluated 10 providers across 22 criteria, the vendors covered in this guide were placed as follows: Akamai, Cloudflare, and Imperva were named Leaders; F5, Fastly, and Radware were named Strong Performers; and Fortinet was named a Contender.
Of the seven platforms covered here, four completed the public SecureIQLab v4.0 cycle: Akamai, Cloudflare, Fortinet, and Imperva. Akamai, Fortinet, and Imperva were placed in the Leader category. F5, Fastly, and Radware are listed as Contact SecureIQLab in the comparative report and did not appear with published v4.0 results.
API traffic now accounts for more than 70% of all web traffic, and independent industry reporting links roughly a third of recent data breaches to APIs, with about 35% of API breaches tied to Broken Object Level Authorization (BOLA). Modern WAAPs need to cover REST, GraphQL, SOAP, WebSockets, and gRPC; independent testing has shown wide variance across protocols even within a single vendor’s product.
Native in-cloud deployment lets a WAAP inspect traffic inside the cloud provider’s own network rather than routing it externally, which can reduce latency and operational overhead and avoid changes to DNS, SSL, or routing. Imperva for Google Cloud, for example, uses Google Cloud Service Extension and Private Service Connect to operate inside the Google Cloud network, and Imperva offers native deployment across AWS, Azure, and Google Cloud.
Look for testing conducted under the Anti-Malware Testing Standards Organization (AMTSO) framework. The SecureIQLab Cloud WAAP v4.0 methodology used in this guide is AMTSO-certified (AMTSO-LS1-TP097). Pair it with analyst evaluations (Forrester, Gartner, KuppingerCole, IDC) and verified peer reviews.
Treat vendor-produced competitive comparisons as marketing inputs rather than evidence. Anchor evaluation on AMTSO-certified independent testing, recent analyst reports, and verified peer reviews, and confirm specific claims through your own proof of value.
Strong WAAP decisions combine three things: independent testing data, analyst guidance, and a proof of value run on your own traffic. As next steps, security leaders typically benefit from running a quick application portfolio baseline (top 20 apps and APIs by risk), executing an internal red-team exercise against current controls, and shortlisting two to three vendors for parallel proof of value testing across the dimensions outlined above.
To explore Imperva’s WAAP capabilities, including native deployment for AWS, Azure, and Google Cloud, or to request a technical evaluation, contact the Imperva team.
All claims in this guide are supported by independent third-party sources or by vendor public documentation for descriptive facts. The full reference list is below.
[1] SecureIQLab, 2025 Cloud WAAP CyberRisk Comparative Validation Report v4.0, AMTSO Test ID AMTSO-LS1-TP097, https://www.secureiqlab.com.
[2] SecureIQLab, 2025 Cloud WAAP CyberRisk Validation Reports (individual vendor reports, including Akamai, Cloudflare, Fortinet, and Imperva).
[3] Anti-Malware Testing Standards Organization (AMTSO), https://www.amtso.org.
[4] Forrester, The Forrester Wave: Web Application Firewall Solutions, Q1 2025 (Sandy Carielli, et al., March 20, 2025). Tier placements and composite scorecard scores cited here are from Figures 1 and 2 of the report.
[5] Gartner, Market Guide for Cloud Web Application and API Protection, most recent edition, https://www.gartner.com.
[6] Gartner Peer Insights, Cloud Web Application and API Protection market reviews, https://www.gartner.com/reviews/market/cloud-web-application-and-api-protection.
[7] G2, Web Application Firewall (WAF) category, verified user reviews and product ratings, https://www.g2.com/categories/web-application-firewall-waf.
[8] KuppingerCole, Leadership Compass: Web Application and API Protection (WAAP), 2025.
[9] IDC, IDC MarketScape for Web Application and API Protection (WAAP).
[10] OWASP Top 10 (2021), https://owasp.org/Top10/.
[11] OWASP API Security Top 10 (2023), https://owasp.org/API-Security/.
[12] MITRE ATT&CK Framework, https://attack.mitre.org.
[13] Lockheed Martin Cyber Kill Chain, https://www.lockheedmartin.com/en-us/capabilities/cyber/cyber-kill-chain.html.
[14] CISA, Secure by Design Principles, https://www.cisa.gov/securebydesign.
[15] PCI Security Standards Council, PCI DSS v4.0, https://www.pcisecuritystandards.org.
[16] SQ Magazine, API Security Breach Statistics 2026, https://sqmagazine.co.uk/api-security-breach-statistics/.
[17] TechRT, API Usage and Growth Statistics 2026, https://techrt.com/api-usage-and-growth-statistics/.
[18] Security Boulevard, 2026 API ThreatStats analysis, https://securityboulevard.com.
[19] Akamai, App & API Protector product page, https://www.akamai.com.
[20] Cloudflare, Application Security product page, https://www.cloudflare.com.
[21] F5, Distributed Cloud WAAP product page, https://www.f5.com.
[22] Fastly, Next-Gen WAF product page, https://www.fastly.com.
[23] Fortinet, FortiWeb product page, https://www.fortinet.com.
[24] Imperva, Web Application and API Protection product page, https://www.imperva.com/products/application-security/.
[25] Imperva, Imperva for Google Cloud product page, https://www.imperva.com/products/imperva-for-google-cloud/.
[26] Imperva, Introducing Imperva for Google Cloud (company blog, 2026), https://www.imperva.com/blog/.
[27] Radware, Cloud Application Protection Service product page, https://www.radware.com.
The post Best WAAP Solutions for Enterprise Application Security: How to Choose the Right Platform in 2026 appeared first on Blog.
There is a question I have been hearing more and more from CISOs, compliance officers, and security architects over the past year. It does not start with “we had a breach” or “we failed an audit.” It starts with something that sounds almost philosophical:
“Are we quantum-safe?”
A year ago, that question came from the most forward-thinking 5% of our customer base. Today, it is coming from everyone. And that shift, from curiosity to urgency, tells you everything you need to know about where the security industry is headed.
Post-Quantum Cryptography is not a future problem anymore. It is a right now problem. And the customers asking us about it are not being paranoid. They are being smart.
What is post-quantum cryptography? Post-quantum cryptography (PQC) is a new generation of public-key algorithms designed to remain secure against attacks from both classical and large-scale quantum computers. Unlike RSA and elliptic-curve cryptography, which rely on math that a sufficiently powerful quantum computer can break, PQC algorithms are based on mathematical problems that are believed to be hard for quantum machines as well -protecting the data your organization encrypts today from being decrypted in the future.
Let us be direct about the threat model, because it is one that does not get nearly enough attention in mainstream security conversations.
You do not need a quantum computer to exist today for your encrypted data to already be at risk.
Sophisticated nation-state adversaries are actively collecting encrypted TLS traffic right now, including your transactions, your authentication sessions, and your sensitive data in transit, with the explicit intention of decrypting it later once quantum computing reaches sufficient capability. This strategy has a name: “Harvest Now, Decrypt Later.” And it is not theoretical. It is happening.
The implication is sobering: the security decisions you make today about encryption determine the confidentiality of data that will still be sensitive in five, ten, or fifteen years. Healthcare records. Financial transactions. Government communications. Intellectual property. Any data with long-term value is already a target for harvesting.
Classical TLS, the encryption backbone of the modern internet, was not built to withstand quantum-scale attacks. The mathematical problems that make RSA and ECC hard to break today become tractable for sufficiently powerful quantum computers. When that threshold is crossed, the encryption protecting decades of harvested data becomes transparent.
This is not a hypothetical edge case. It is a strategic, long-horizon attack that demands a strategic, long-horizon defense.
Here is something I want to be transparent about, because I think it matters.
At Thales, we have been getting questions about PQC readiness from customers consistently and with increasing frequency. These are not fringe inquiries from academic researchers or early adopters chasing the next shiny thing. These are enterprise security teams, regulated industry customers in finance, healthcare, and defense, and compliance officers who are watching the regulatory horizon and doing the math.
They are thinking about it. And they deserve a vendor who is already ahead of it.
That is exactly why I am proud to share what we have built. Thales’ Imperva platform now supports hybrid TLS handshakes combining X25519 and MLKEM768, a pairing of classical elliptic curve cryptography with a quantum-safe Key Encapsulation Mechanism aligned directly with NIST PQC standards. This hybrid approach protects connections between clients and Imperva Points of Presence with both classical and quantum-safe algorithms running simultaneously, ensuring security regardless of which threat model materializes first.
And we did not just build the capability for customers. We completed the migration of all Imperva sites ourselves. We validated it in production before asking anyone else to trust it.
That is what proactive security looks like.
I know “hybrid TLS handshake” can sound abstract, so let me ground it in something concrete.
When a client connects to a Thales Imperva-protected application today, that TLS 1.3 session is authenticated using X25519MLKEM768, a combined algorithm that you can actually observe directly if you inspect the connection in Chrome’s security panel. You will see exactly what the screenshot above shows: “The connection to this site is encrypted and authenticated using TLS 1.3, X25519MLKEM768, and AES_128_GCM.”
That is not marketing language. That is your browser’s own security panel confirming quantum-safe encryption is active.
What this means practically:
The hybrid model is deliberate and important. Pure PQC algorithms, while mathematically quantum-resistant, are newer and have had significantly less real-world cryptanalysis time than their classical counterparts. The hybrid approach ensures we are not trading one risk for another. We are stacking defenses. This is defense-in-depth applied to cryptography itself.
Here is the objection I hear almost every time PQC comes up in a customer conversation: “That sounds computationally expensive. What does it do to latency?”
The answer, which genuinely surprises most people: nothing measurable.
Our PQC implementation introduces no performance trade-off and no traffic impact. This matters enormously because one of the most common reasons organizations delay critical security upgrades is the perceived performance cost. Security teams propose the upgrade. Engineering teams push back on latency. The initiative stalls.
With Thales’s PQC implementation, that objection is gone.
Quantum-safe encryption that slows your applications down is not a real solution. It is a compliance checkbox that creates new operational problems while solving a cryptographic one. We were not willing to ship that. The implementation delivers genuine quantum-safe security without the operational tax, and that is the only version of this capability worth deploying at enterprise scale.
If the threat model alone is not enough to create urgency in your organization, and for some organizations it is not, that is an honest reality, then the regulatory and compliance landscape should be.
Governments and standards bodies have moved decisively and fast:
The direction is unambiguous. Regulated industries, including finance, defense, and healthcare, are going to face PQC compliance requirements. The organizations that begin migration now will meet those requirements ahead of schedule, with time to test, validate, and optimize. The ones that wait will be scrambling to meet deadlines under pressure.
Thales’s PQC support is directly aligned with enterprise and regulated sector expectations today. When your auditor, your regulator, or your enterprise customer asks whether your traffic is quantum-safe, the answer should already be yes.
I want to address something directly, because the way PQC gets discussed in the media can make it sound like a complete overhaul that requires ripping out and replacing your entire security infrastructure overnight.
That framing is not helpful. And it is not accurate.
PQC is a security evolution. The underlying architecture of TLS, certificates, and encrypted communications does not change. The mathematical primitives powering key exchange and authentication do. For most organizations, particularly those working with a security partner like Imperva that has already done the migration work, the path forward is far more manageable than the “quantum apocalypse” narrative suggests.
The hybrid approach makes this especially true. You do not abandon classical cryptography overnight. You layer quantum-safe algorithms alongside proven ones, maintain backward compatibility where needed, and progressively increase quantum-safe coverage as the ecosystem matures and client-side support expands.
Supporting our customers to be PQC compliant at the start of the year was just one step in that evolution. It is a step we took proactively, before our customers needed to ask twice, because that is what it means to be a security partner rather than just a security vendor.
If you are a CISO, a security architect, or a compliance officer reading this, here is where I would focus your energy:
The harvest is already happening. The standards are finalized. The regulatory expectations are forming. And the technology to protect yourself, without performance trade-offs, without ripping out your stack, is available right now.
Our customers are asking about PQC readiness because they understand the stakes. They are thinking about long-horizon risk in a way that their boards and regulators are increasingly demanding. And they deserve a security partner who is not just thinking about it alongside them but has already built, tested, and deployed the answer.
Post-Quantum Cryptography is not a problem for the security teams of 2030. It is a problem for the security teams of today, being solved by the tools available today.
Thales is quantum-ready.
The question is: are you?
Thales Imperva’s Post-Quantum Cryptography support, hybrid TLS with X25519 plus MLKEM768 for Client to Imperva connections, reached General Availability at the start of 2026. To learn more about Imperva’s PQC readiness and what it means for your organization, contact us or explore our Cloud WAF capabilities.
What is post-quantum cryptography (PQC)?
Post-quantum cryptography is a set of public-key algorithms designed to remain secure against attacks from large-scale quantum computers. It replaces or augments classical algorithms like RSA and elliptic-curve cryptography, whose underlying math a sufficiently powerful quantum computer could break.
What is a “harvest now, decrypt later” attack?
“Harvest now, decrypt later” is a strategy in which adversaries collect and store encrypted traffic today so they can decrypt it once quantum computers become powerful enough to break classical public-key cryptography. Any data that will still be sensitive in five to fifteen years—healthcare records, financial transactions, intellectual property—is already a target.
What is ML-KEM (FIPS 203)?
ML-KEM (Module-Lattice-based Key-Encapsulation Mechanism) is the NIST-standardized post-quantum key exchange specified in FIPS 203, published August 13, 2024. Imperva pairs ML-KEM-768 with the classical X25519 key exchange to form a hybrid TLS handshake—giving every connection both classical and quantum-safe protection.
Why pair a quantum-safe algorithm with a classical one (hybrid TLS)?
Pure PQC algorithms are mathematically quantum-resistant but have had far less real-world cryptanalysis than RSA or elliptic-curve cryptography. A hybrid handshake runs both classical and PQC key exchange together: an attacker would have to break both to compromise the session. It is defense-in-depth for cryptography itself, and it’s the recommended posture for 2026.
Is Imperva quantum-safe today?
Yes. Thales Imperva’s PQC support, hybrid TLS combining X25519 and ML-KEM-768 for client-to-Imperva connections, reached general availability at the start of 2026. All Imperva sites have already been migrated. For setup details and current handshake scenarios, see the Imperva PQC support documentation.
The post The Clock Is Already Ticking: Why Post-Quantum Cryptography Can’t Wait appeared first on Blog.
Every security team knows the pain: a critical alert lands in someone’s inbox, buried under dozens of other emails, or filtered out by a spam rule. By the time anyone sees it, the incident is already in full swing—no ticket opened, no Slack message sent, no automated workflow triggered. The detection worked, but the notification system didn’t.
Email was always a compromise for security notifications. It’s universal, but that’s also its weakness:
The stakes are high. Imperva research found that 44% of security professionals spend more than 20 hours a week responding to alerts, and 27% of IT professionals receive more than a million security alerts a day. When a critical notification is lost in that flood, response slows down—exactly when speed matters most.
The result? An operational gap between detection and response. That gap closes today.
What are webhook notifications? Webhook notifications are automated, real-time messages that a system sends to a URL you choose the moment an event occurs. Instead of waiting for someone to open an email, the event data—usually structured as JSON—is pushed straight to your tools, where it can instantly trigger tickets, alerts, and automated workflows.
Imperva now supports webhook notifications: real-time, structured alerts delivered directly to your systems and tools. You define webhook connections in the Imperva Platform, assign them to notification policies, and from then on, your alerts go exactly where you need them—instantly, in a format your automation can use.
No more spam filters. No more manual ticket creation. No more copy-pasting data at midnight.
*Note: Some notification types and integrations (like Slack/Teams) are coming soon or in beta. See documentation for current coverage.
Webhook notifications are designed for enterprise reliability:
Webhook notifications aren’t just a new channel—they’re an automation unlock. Every alert becomes a programmable trigger: DDoS events, site configuration, bandwidth thresholds. Your automation stack gets a clean, reliable feed for every significant event, enabling faster, more consistent response. This is the foundation of SOC automation: every Imperva alert becomes a programmable trigger for faster, more consistent incident response.
When alerts arrive as structured events, action no longer depends on someone noticing an email. Notifications flow straight into tickets, incident channels, or automated workflows—so the right response happens immediately and consistently.
There’s nothing new to install. Webhook connections are configured directly in the Imperva platform under Accounts – Webhook Connection. You name the connection, define the endpoint URL, and assign it to the desired notification policy
Today, webhook notifications work alongside email—so you can run both channels in parallel and migrate at your own pace.
What are webhook notifications?
Webhook notifications are automated, real-time messages that Imperva sends to a URL you define the moment a security or operational event occurs. The event is delivered as structured data your tools can act on immediately—opening tickets, posting to chat channels, or triggering automated workflows—without anyone reading an email first.
How are webhook notifications more reliable than email security alerts?
Email alerts can be lost to spam filters or buried in crowded inboxes. Webhook notifications are delivered directly to your systems, with backoff logic that retries delivery if your endpoint is temporarily unreachable and optional authentication codes in the webhook header to verify each message. The result is fewer missed alerts and a structured payload your automation can parse reliably.
What security events can trigger an Imperva webhook?
Webhook notifications can fire on events such as a DDoS attack starting or stopping, an SSL certificate nearing expiration, a new site that needs DNS configuration, and bandwidth overage warnings. Each event is sent to the notification policy you assign it to. Some notification types and integrations are rolling out over time, so check the Imperva documentation for current coverage.
Can I use webhook and email notifications at the same time?
Yes. Webhook notifications run alongside email, so you can keep both channels active and migrate to webhooks at your own pace. Many teams keep email as a backup while webhooks become the primary channel for automated response.
How do I set up webhook notifications in Imperva?
There is nothing new to install. In the Imperva Platform, go to Accounts – Webhook Connection, name the connection, define the endpoint URL, and assign it to the notification policy you want. For step-by-step instructions and current event coverage, see the Imperva webhook documentation.
Webhook notifications mean fewer missed alerts, faster automation, and less manual work. Email becomes your backup, not your primary channel. At this stage access to webhook notifications is currently limited, get in touch to find out more.
Your security workflows just got an upgrade.
Contact your Imperva account team to find out more.
The post Real-Time Webhook Notifications: No More Lost Security Alerts appeared first on Blog.
The company blocked over 1.1 billion accounts and $2.2 billion in potentially fraudulent transactions.
The post Apple Rejected 2 Million App Store Submissions in 2025 for Security and Fraud Prevention appeared first on SecurityWeek.
Digital.ai’s latest threat report warns that agentic AI has erased the distinction between emerging and primary targets, enabling attackers to strike mobile apps within hours of release across every industry.
The post AI-Powered App Attacks Are Faster, More Frequent and Harder to Stop appeared first on SecurityWeek.
Login
