Top 8 API Security Testing Providers for REST, GraphQL, and SOAP

What Is API Security Testing for REST, GraphQL, and SOAP? 

To secure diverse API environments, organizations must address modern architectures (REST and GraphQL) as well as legacy protocols (SOAP/XML). API security testing is the process of evaluating application programming interfaces (APIs) to identify vulnerabilities, misconfigurations, and security gaps that attackers could exploit. This practice covers both manual and automated methods to ensure APIs function securely under various conditions. 

The following table summarizes the unique security requirements of each type of API:

In this article we cover the following API security testing providers:

Testing-first API security platforms:

• Checkmarx API security: Code-first API discovery and testing with SAST/DAST correlation, strong for finding shadow and zombie APIs in source.
• StackHawk: CI/CD-focused dynamic API testing for REST, GraphQL, SOAP, and gRPC, with attack simulation and developer-friendly evidence.
• 42Crunch: Contract-first API security platform that audits OpenAPI definitions and dynamically tests implementations for conformance.
• Burp Suite DAST: Enterprise dynamic scanner for web apps and APIs, using Burp Scanner, API definition parsing, authenticated scans, and OAST.

API discovery and runtime protection platforms:

• Salt Security: Runtime API discovery and behavioral threat detection platform for large API estates, with posture governance and SIEM/ticketing workflows.
• Akamai API security: Multi-source API discovery, preproduction testing, and runtime monitoring across hybrid, multicloud, and on-prem environments.
• Imperva API security: API discovery, risk assessment, BOLA detection, and inline mitigation, especially suited to teams already using Imperva WAF.
• Cequence security: API posture, testing, compliance mapping, sensitive data controls, and inline attack blocking with native bot mitigation.

Why REST, GraphQL, and SOAP Require Different Security Testing Approaches

REST API Security

REST is an architectural style for building APIs over HTTP rather than a formal protocol. REST APIs typically expose resources through URLs and use HTTP methods such as GET, POST, PUT, PATCH, and DELETE. They commonly exchange JSON data and rely on HTTP mechanisms for authentication, caching, status codes, and transport security.

Key REST API security challenges include:

• Broken object-level authorization: Attackers can manipulate resource identifiers to access another user’s records if authorization is not checked for every object.
• Broken function-level authorization: APIs can expose administrative or privileged operations when permissions are enforced inconsistently across endpoints and HTTP methods.
• Authentication weaknesses: Poor token validation, long-lived credentials, insecure session handling, or incorrectly configured OAuth can enable account compromise.
• Mass assignment: Automatically mapping request fields to internal objects can let attackers modify sensitive properties that should not be user-controlled.
• Injection attacks: Unsanitized parameters, headers, or request bodies can introduce SQL, command, or other injection vulnerabilities.
• Excessive data exposure: Endpoints can return complete internal objects instead of limiting responses to fields the client is authorized to receive.
• Missing resource limits: Weak rate limiting and request-size controls can allow brute-force attacks, scraping, or resource exhaustion.

REST API security strategy:

REST security testing should focus on each endpoint, HTTP method, parameter, and resource identifier. Testers should verify authentication and object- and function-level authorization by modifying IDs, tokens, methods, and request fields. 

Testing should also cover input validation, mass assignment, response data exposure, rate limits, and request-size controls. Because REST APIs often depend on OAuth or bearer tokens, token validation, expiration, scope enforcement, and transport security should also be tested.

Related content: Read our detailed guide to SQL injection.

GraphQL API Security

GraphQL is an API query language and runtime specification that lets clients request specific fields from a defined schema. Unlike REST APIs with many resource-oriented endpoints, GraphQL commonly exposes a single endpoint where clients send queries, mutations, and sometimes subscriptions. Clients can also request related objects within one operation.

Key GraphQL API security challenges include:

• Complex query denial of service: Deeply nested, recursive, or expensive queries can consume excessive CPU, memory, database connections, or network resources.
• Authorization at field and resolver level: A request may be allowed to access an object but not every field within it. Authorization must therefore be enforced beyond the top-level query.
• Batching abuse: GraphQL aliases and batched operations can allow attackers to perform many actions in one HTTP request, potentially bypassing request-based rate limits.
• Introspection exposure: Introspection can reveal available types, fields, mutations, and relationships, giving attackers useful information about the API’s attack surface.
• Injection vulnerabilities: Arguments passed through resolvers can reach databases, operating system commands, or downstream services and become injection vectors if handled insecurely.
• Excessive data access: Flexible queries can expose sensitive fields or relationships when schema permissions and resolver authorization are incomplete.
• Subscription security: Long-lived GraphQL subscriptions require authentication and authorization throughout the connection lifecycle, not only when the connection is established.

GraphQL API security strategy:

GraphQL security testing should focus on the schema, resolvers, and the cost of operations rather than only the HTTP endpoint. Testers should verify authorization for individual fields, objects, mutations, and subscriptions, including access through nested relationships. 

They should also test query depth and complexity limits, aliases, batching, introspection controls, and rate limiting based on operation cost rather than request count alone. Resolver arguments should be tested for injection and unauthorized data access.

SOAP API Security

SOAP is a standardized messaging protocol for exchanging structured data between applications. SOAP messages use XML envelopes and are commonly transported over HTTP or HTTPS. SOAP services can use standards from the WS-* family, including WS-Security for message-level authentication, integrity, confidentiality, and security tokens.

Key SOAP API security challenges include:

• XML external entity attacks: Insecure XML parsers can process external entities, potentially exposing local files, enabling server-side request forgery, or causing resource exhaustion.
• XML-based denial of service: Large, deeply nested, or specially constructed XML documents can consume excessive parser memory and CPU.
• XML signature wrapping: Attackers can modify SOAP message structure so that signature validation succeeds while the application processes attacker-controlled content.
• WS-Security misconfiguration: Incorrect handling of signatures, encryption, timestamps, or security tokens can weaken authentication and message integrity protections.
• Replay attacks: Signed SOAP messages can be captured and resent if timestamps, nonces, message identifiers, and expiration rules are not validated correctly.
• WSDL information exposure: Publicly accessible Web Services Description Language (WSDL) documents can reveal operations, data structures, service locations, and other details useful for mapping the attack surface.
• Legacy implementation risks: SOAP is common in older enterprise systems that may use outdated XML libraries, authentication mechanisms, cryptographic algorithms, or dependencies.

SOAP API security strategy:

SOAP security testing should examine both XML processing and the WS-Security controls applied to messages. Testers should send malformed, oversized, and malicious XML to identify unsafe entity handling and parser resource limits. 

They should also verify XML signatures and encryption, including which message elements are protected, and test timestamps, nonces, and message identifiers for replay protection. WSDL exposure, authentication controls, cryptographic settings, and outdated XML or SOAP components should also be reviewed.

API Security Testing Providers at a Glance

The table below summarizes the key differences between the solutions covered in this guide. We explore each one in more detail in the sections that follow.

Related content: Read our guide to the types of application security testing.

Key Capabilities of API Security Testing Solutions 

API Discovery and Inventory

API discovery and inventory are foundational capabilities for any API security testing solution. Modern environments often contain undocumented or “shadow” APIs, legacy endpoints, and third-party integrations that may not be tracked by development teams. Automated discovery tools scan network traffic, code repositories, and infrastructure configurations to identify all active APIs. This visibility is critical for understanding the full attack surface and ensuring that every API, not just those officially documented, is included in security assessments.

Once APIs are discovered, maintaining an up-to-date inventory is essential for risk management and compliance. Inventory tools categorize APIs by type, usage, and sensitivity, helping organizations prioritize testing efforts. They track changes over time, flagging new or modified endpoints that may introduce vulnerabilities. An accurate inventory supports better incident response and facilitates compliance with data protection regulations, as organizations can quickly identify which APIs handle sensitive data and require enhanced security measures.

Protocol-Aware Testing

Protocol-aware testing adapts security checks to the API technology being assessed rather than treating every API as generic HTTP traffic. For REST APIs, tools should understand resource paths, HTTP methods, status codes, JSON payloads, and specifications such as OpenAPI. This enables targeted tests for issues such as broken object-level authorization, mass assignment, and inconsistent access controls across methods.

GraphQL testing requires understanding queries, mutations, variables, aliases, batching, introspection, and nested fields. SOAP testing requires XML and WSDL awareness, including SOAP envelopes, XML parsers, and WS-Security controls. Protocol-aware tools can therefore test risks such as GraphQL query complexity and resolver authorization or SOAP-specific XXE, signature wrapping, and replay vulnerabilities.

Automated Vulnerability Scanning

Automated vulnerability scanning is a core feature of API security testing platforms. These scanners simulate attacks against API endpoints to identify common vulnerabilities such as broken authentication, excessive data exposure, injection flaws, and insecure configurations. Automated tools leverage predefined rules and signatures based on standards like the OWASP API Security Top 10, enabling rapid detection of known security issues across large API portfolios without manual intervention.

Beyond identifying known vulnerabilities, advanced scanners can also detect configuration drift, outdated dependencies, and misaligned security controls. They provide detailed reports with severity ratings and remediation guidance, allowing security teams to prioritize fixes effectively. Automated scanning accelerates the testing process, supports continuous integration and delivery workflows, and reduces the risk of human error that can occur in manual reviews. Consistent, automated testing ensures APIs remain secure as they evolve.

Authentication and Authorization Testing

Authentication and authorization are critical components of API security, and dedicated testing is necessary to ensure these controls are correctly implemented. Testing tools validate that APIs require proper credentials for access and enforce role-based or attribute-based access control consistently across endpoints. They simulate attacks such as credential stuffing, token reuse, and privilege escalation to uncover weaknesses in authentication flows and session management.

Authorization testing also examines whether users can access only the resources and actions they are permitted to. This includes testing for vulnerabilities like insecure direct object references (IDOR) and broken access control, which can lead to unauthorized data exposure or manipulation. Effective solutions automate these checks across various user roles and permission levels, identifying gaps that could be exploited. Comprehensive authentication and authorization testing helps prevent data breaches and ensures compliance with security best practices.

API Schema and Specification Testing

API schema and specification testing verifies that API implementations conform to their defined contracts, such as OpenAPI (Swagger), RAML, or WSDL specifications. Tools in this category parse the API schema and test endpoints to ensure they accept only valid input and return responses that match the expected structure. Discrepancies between the schema and actual behavior can indicate potential security flaws, such as improper data validation or exposure of undocumented fields.

Testing the schema also helps identify versioning issues, deprecated endpoints, and inconsistencies that may confuse consumers or introduce vulnerabilities. Automated schema validation ensures that changes to the API do not break compatibility or introduce unexpected behaviors. By enforcing strict adherence to specifications, organizations can reduce the risk of implementation errors, improve API reliability, and maintain a clear contract between development teams and API consumers.

Business-Logic and Access-Control Testing 

Authorization and business-logic testing examines whether an API enforces rules correctly across users, resources, actions, and application workflows. Effective tools replay and modify requests under different identities to test horizontal privilege escalation, vertical privilege escalation, object-level authorization, and access to administrative functions. They should also vary resource identifiers, HTTP methods, parameters, and workflow states rather than relying only on response status codes.

Business-logic testing targets flaws that conventional vulnerability signatures may not detect. Examples include bypassing required workflow steps, applying a discount repeatedly, submitting duplicate transactions, manipulating prices or quantities, and performing operations in an invalid sequence. Because these tests depend on application context, stronger solutions combine automation with configurable workflows, user roles, state tracking, and manual validation.

Fuzz Testing

Fuzz testing sends malformed, unexpected, or randomly generated data to API inputs to uncover weaknesses in validation and error handling. Tests can modify query parameters, headers, path values, request bodies, and content types while monitoring responses for crashes, excessive errors, information leakage, or other abnormal behavior. Schema-aware fuzzers can use an API specification to generate inputs that target each documented field and data type.

Security-focused fuzzing tests boundary values, oversized payloads, invalid encodings, unexpected data types, special characters, and unusual combinations of otherwise valid inputs. It can expose injection flaws, parser errors, unhandled exceptions, and resource exhaustion conditions. Automated fuzzing is particularly useful for repeatedly testing large API surfaces as endpoints and schemas change.

Finding Validation and Remediation

Finding validation helps security teams distinguish exploitable vulnerabilities from scanner noise. A testing solution should preserve the request, response, affected endpoint, authentication context, and other evidence needed to reproduce a finding. Where safe, validation can repeat or vary an attack to confirm that the observed behavior is consistent and caused by the suspected vulnerability.

Remediation features should translate validated findings into actionable development tasks. Useful context includes severity, exploit conditions, affected API operations, relevant code or configuration, and specific mitigation guidance. Integrations with issue trackers and security platforms can route findings to the responsible team, while retesting verifies that fixes are effective and helps prevent resolved vulnerabilities from being reopened unnecessarily.

CI/CD and DevSecOps Integration

CI/CD integration allows API security tests to run automatically as part of build, test, and deployment pipelines. Security checks can be triggered when code or API specifications change, helping teams identify vulnerabilities before they reach production. Testing solutions can integrate with source control, build systems, issue trackers, and deployment platforms to make security findings part of existing development workflows.

DevSecOps integrations can enforce security gates based on criteria such as vulnerability severity, affected endpoints, or policy violations. Results should provide developers with enough request, response, and remediation detail to reproduce and fix each issue. Running targeted tests on every change and broader scans at scheduled intervals provides continuous coverage without making every pipeline run unnecessarily slow.

Notable API Security Testing Solutions

How we selected these solutions: We shortlisted API security testing solutions based on API discovery and inventory, protocol coverage across REST, GraphQL, and SOAP, automated vulnerability and business logic testing, authentication and authorization checks, and integration into CI/CD and runtime workflows.

Testing-First API Security Platforms

1. Checkmarx API Security

Best for: Discovering and testing APIs from application source code

Strengths: Code-based discovery with correlated SAST and DAST findings

Things to consider: Scan and report times can stretch on large builds

Checkmarx API Security is part of the Checkmarx One platform. It scans application source code and API documentation to build an inventory of every API defined in an application, including shadow APIs that carry no documentation and zombie APIs left running after version migrations.

Because discovery starts in code rather than in traffic, APIs that sit outside a WAF or gateway configuration are still catalogued. Static findings are then correlated with dynamic testing results, so each endpoint in the inventory carries both code-level and runtime evidence.

Checkmarx correlates runtime risk through integration with Checkmarx DAST rather than providing native runtime protection. Static findings from source code and dynamic findings from DAST testing appear against the same endpoint in one inventory, giving teams earlier visibility into which pre-production risks are confirmed exploitable at runtime. 

Key features include:

• Global API inventory: Lists every API discovered in the application together with the vulnerabilities detected on it, and orders remediation by business risk rather than CVSS score alone.
• Source code API discovery: Scans repositories to find and inventory APIs defined in code, including undocumented shadow APIs and abandoned zombie endpoints that gateways and WAFs cannot see.
• API documentation scanning: Reads OpenAPI, Swagger, and Postman collections and compares them against the code-derived inventory to flag data discrepancies and undocumented endpoints.
• API change log: Records the history of every API change, showing which commit introduced a risk, which developer made the change, and how the API was defined beforehand.
• DAST correlation: Presents SAST and DAST results in a single API inventory. When both flag the same endpoint, the finding is elevated in priority as confirmed exploitable at runtime.
• OWASP API Top 10 mapping: Detects vulnerabilities mapped to categories such as Broken Object Level Authorization, broken authentication, and excessive data exposure during SAST scanning of API code.

Limitations (as reported by users on PeerSpot):

• Scan and reporting duration: Builds and vulnerability reports can take tens of minutes on larger codebases, which slows feedback inside CI pipelines.
• Report and dashboard customization: Reporting relies on supplied templates, and users have asked for editable reports and more configurable dashboard views.
• Manual verification of findings: Some results still need manual review to rule out false positives before developers act on them.

Discover every API in your codebase and address vulnerabilities earlier in the SDLC

Checkmarx API Security

Shift left and integrate right and address vulnerabilities earlier and faster in the SDLC.

Explore the Platform

[Simple CTA]

Pre-title: Discover every API in your codebase and address vulnerabilities earlier in the SDLC

Title: Checkmarx API Security

CTA line: Learn More

URL: https://checkmarx.com/product/api-security/ 

2. StackHawk

Strengths: Covers REST, GraphQL, SOAP, and gRPC with attack simulation

Best for: Automated API security testing inside CI/CD pipelines

Things to consider: Pipeline setup for dependent microservices takes effort

StackHawk runs dynamic security tests against running applications and APIs from inside CI/CD pipelines. It simulates real-world attacks against gRPC, GraphQL, REST, and SOAP endpoints and reports the vulnerabilities it can reach, so testing happens before code ships rather than after deployment.

Scans are triggered on every pull request, and each finding is returned with the request and response evidence that produced it. Test scenarios can be tailored with specific input values and shaped around an application’s own architecture and business logic.

Key features include:

• Coverage for all API types: Automates security testing across gRPC, GraphQL, REST, and SOAP services using simulated attack traffic rather than static inspection.
• Custom test scenarios: Allows teams to set specific key input values for API requests and build tailor-made scenarios that mimic real user interactions and attack patterns.
• Business logic and edge case testing: Identifies security vulnerabilities and edge cases unique to the application’s architecture and business logic rather than only generic signatures.
• LLM-integrated API testing: Tests APIs connected to LLMs for prompt injection, data disclosure, and output handling vulnerabilities.
• CI/CD integration: Uses a Docker-based scanner deployment with configuration managed through code, integrates with tooling such as GitHub, and supports customizable logic for blocking or passing a build.
• Developer triage detail: Every finding includes vulnerability overviews, fix guides, request and response evidence, a cURL command that recreates the issue, and triage through ticketing tools.

Limitations (as reported by users on PeerSpot):

• Pipeline setup for dependent services: Reaching microservices that depend on supporting infrastructure such as databases or message brokers required extra work to stand those services up before scanning.
• Language and framework coverage: Codebases outside the supported set are not covered, which can create gaps after acquisitions or when teams adopt less common stacks.
• Cost: Reviewers considered the product expensive relative to competing dynamic testing offerings.

Source: StackHawk

3. 42Crunch

Best for: Contract-first API testing built on OpenAPI definitions

Strengths: Static OpenAPI audit paired with dynamic conformance scanning

Things to consider: Advanced configuration and alert volume take time to tune

42Crunch approaches API security testing through the OpenAPI contract. API Audit performs static analysis of an OpenAPI or Swagger definition, and API Scan tests the underlying implementation of the API against that same definition. Both are available in developer IDEs and in CI/CD platforms.

Because APIs are specified early in the development lifecycle and have a defined contract, that contract becomes the reference point for testing. API Protect can be added on top for runtime protection once the API is deployed.

Key features include:

• OpenAPI security audit: Runs static analysis of the OpenAPI or Swagger definition file to confirm it adheres to the specification and to catch security issues aligned to the OWASP API Security Top 10.
• Audit scoring and reporting: Auto-generates a report capturing contract-level vulnerabilities such as mass assignment, data and exception leakage, weak authentication schemes, injection vulnerabilities, and lack of resource control.
• Dynamic API scan: Simulates real API traffic with randomly generated requests and parameters to test how the API behaves under real-world conditions.
• Contract conformance checking: Validates that the running API conforms to the definition that was audited, rather than only checking for known vulnerability signatures.
• IDE and CI/CD execution: Both audit and scan run inside developer IDEs and CI/CD platforms, so checks happen within existing development workflows.
• Runtime protection add-on: API Protect can be layered onto the testing tools to enforce the contract once the API is in production.

Limitations (as reported by users on Gartner Peer Insights):

• Learning curve on advanced features: Some advanced capabilities take time to master, particularly for users who are not security specialists.
• Setup and configuration effort: Initial setup and configuration can be time-consuming and may require additional guidance or training.
• Alert volume: The platform can surface a large number of alerts, which makes it harder to prioritize the critical issues.
• Report and policy customization: Options for customizing reports and policies are described as limited and could be more flexible.

Source: 42Crunch

4. Burp Suite DAST

Best for: Enterprise-scale dynamic scanning of web apps and APIs

Strengths: Burp Scanner engine, API definition parsing, automated OAST

Things to consider: False positives and heavy resource use during scans

Burp Suite DAST applies the Burp Scanner engine to automated scanning across large web and API portfolios. Sites are set up individually or in bulk, all that is needed is a URL, and scans can be scheduled on a daily, weekly, or monthly basis or triggered from a CI/CD pipeline.

The scanner parses JSON and YAML API definitions and scans the API endpoints it finds. It uses an embedded browser to render its target, which allows it to navigate complex single-page applications during a crawl.

Key features include:

• API definition parsing: Burp Scanner reads JSON or YAML API definitions and scans any API endpoints it discovers within them.
• Authenticated scanning: Tests privileged areas of target applications, including those protected by complex login mechanisms such as single sign-on.
• Out-of-band testing: Automated OAST, pioneered by PortSwigger, identifies vulnerability classes that produce no visible response in the application itself.
• Scan configuration control: Preset scan modes range from lightweight to deep, and custom configurations set crawl link depth, which vulnerabilities are reported, and fast versus exhaustive results.
• CI/CD and issue tracker integration: Connects to any CI/CD platform and to Jira, GitLab, and Trello with auto ticket generation and severity or confidence triggers, plus a GraphQL API for initiating, scheduling, and cancelling scans.
• Reporting and compliance views: Graphical dashboards break issues down by severity and type, HTML reports are exportable at a chosen level of detail, and checks cover vulnerabilities relevant to PCI DSS and the 2021 OWASP Top 10.
• Extensibility: Burp extensions written in-house or downloaded from the BApp Store tailor the scanner to specific targets and help reduce false positives.

Limitations (as reported by users on PeerSpot):

• False positives: Teams report spending time separating false positives from real findings before passing issues to development.
• Scan performance: High CPU usage and slower scanning speeds have been reported on larger targets.
• API scanning depth: Users have asked for stronger API scanning capabilities, including integration with Postman collections.
• Reporting and interface: Reporting output and dashboard usability are cited as areas that need work.
• Pricing: Annual per-user licensing is seen as high in some regions.

Source: Burp Suite

API Discovery and Runtime Protection Platforms

5. Salt Security

Best for: Continuous API discovery and behavioral threat detection

Strengths: Traffic-based discovery, posture governance, attack detection

Things to consider: Implementation and alert tuning can take time

Salt Security’s platform, Illuminate, analyzes live API traffic to map the APIs running in production across an organization’s environments. Coverage includes shadow APIs, third-party connections, and deprecated endpoints, and discovery runs without manual tagging or agents.

Alongside discovery, the platform assesses API posture against compliance frameworks and applies behavioral analysis to detect API-specific attacks. Findings feed into the tools teams already use, including SIEM platforms, ticketing systems, and firewalls.

Key features include:

• Traffic-based API discovery: Provides real-time visibility into every API running in production across environments, including shadow APIs, third-party connections, and deprecated endpoints.
• Posture and compliance mapping: Continuously analyzes API posture and maps it to frameworks such as PCI DSS, GDPR, NIST, and SOC 2, showing where controls are missing, misaligned, or out of date.
• Policy Hub governance: Enforces API security governance at scale through centrally managed policies.
• Behavioral threat detection: Patented behavioral analysis detects API-specific threats, fraud patterns, and low-and-slow attacks that unfold over extended periods.
• Modular platform components: Salt Surface maps external exposure, Salt Connect covers APIs in cloud accounts, Salt Collect analyzes live traffic data, Salt Protect blocks logic-based threats, and Salt Code enforces policy inside AI coding agents.
• Workflow integrations: Enriches alerts in SIEM tools, closes gaps through Jira tickets, and drives blocking at the firewall.

Limitations (as reported by users on PeerSpot):

• Implementation complexity: Deployments in unusual environments can take time to work through, and there is a learning curve before teams are comfortable with the platform.
• Alert tuning: Tuning can require time depending on API volume, and some findings need internal validation before they are actioned.
• Fit for smaller environments: Reviewers noted the platform is oriented toward larger API estates and can feel complex for smaller organizations.
• Cost of expansion: Adding APIs beyond the initial scope was described as expensive.
• Integration coverage: Some specific integrations are not available out of the box and need to be built.

6. Akamai API Security

Best for: API discovery, testing, and runtime monitoring across estates

Strengths: Multi-source discovery with 200+ preproduction security tests

Things to consider: Policy tuning and role controls need more granularity

Akamai API Security discovers APIs across runtime traffic, code repositories, API documentation, gateways, cloud environments, and external exposure points, then maintains a continuously updated inventory from those sources. It is vendor-neutral, does not require other Akamai products, and runs across multicloud, hybrid, and on-premises environments.

The product covers four lifecycle stages: discover, test, detect, and respond. Testing runs in CI/CD and preproduction workflows, while runtime analysis examines how APIs behave once they are live.

Key features include:

• Multi-source API discovery: Builds an inventory from traffic, code, specifications, gateways, cloud environments, and external exposure points, including shadow, zombie, unmanaged, MCP, and AI-linked APIs.
• Preproduction security testing: Runs more than 200 API security tests in CI/CD and preproduction workflows that simulate malicious traffic, including tests aligned to the OWASP API Security Top 10.
• Posture and compliance mapping: Measures APIs against internal policies and frameworks including OWASP API, PCI DSS, HIPAA, ISO 27001, GDPR, HITRUST, and NIST.
• Runtime behavioral analysis: Analyzes runtime behavior to detect abnormal activity, business logic abuse, sensitive data exposure, data scraping, tampering, and attacks.
• Ownership mapping: Maps API findings to owners, repositories, file paths, and last committers where that information is available.
• Response routing: Sends findings into SIEM, ITSM, ticketing, CMDB, WAAP, gateway, and developer workflows.
• North-south and east-west coverage: Analyzes API traffic from supported north-south and east-west sources, depending on how traffic is connected.

Limitations (as reported by users on PeerSpot):

• Policy tuning granularity: Users want finer control over policy tuning and clearer visibility into how behavioral decisions are reached.
• Alerting and notifications: Built-in notification for repeated activity from a single source is limited, and some teams add a third-party tool for alerting.
• Third-party integrations: SIEM and SOAR integration is described as needing work before incident response workflows can be fully automated.
• Configuration learning curve: Adoption takes time, and the depth of available customization adds complexity and lengthens training for new administrators.
• Dashboard customization: On-demand executive reporting views were requested by reviewers.

Source: Akamai

7. Imperva API Security

Best for: API discovery and protection alongside an existing WAF

Strengths: Continuous discovery, BOLA detection, inline mitigation

Things to consider: Reporting workflow and on-premises coverage have gaps

Imperva API Security brings API discovery, risk assessment, detection, and mitigation into a single console across cloud, on-premises, and hybrid environments. It continuously discovers public, private, and shadow APIs, tracks changes to them, and classifies the sensitive data they carry.

Detection combines behavioral and rule-based engines to score anomalies and flag risky endpoints, while mitigation is enforced inline through Cloud WAF and WAF Gateway. A shift-left option scans an uploaded API specification before code ships.

Key features include:

• Continuous discovery and classification: Discovers and monitors public, private, and shadow APIs across environments, tracks changes, and classifies endpoints by data sensitivity, including government ID, payment card details, address information, and other PII.
• Risk assessment against OWASP API Top 10: Runs ongoing risk assessments of API endpoints to identify design flaws and vulnerabilities associated with the OWASP API Security Top 10.
• Business logic threat protection: Detects Broken Object Level Authorization risks in real time using hybrid behavioral and rule-based engines, with automated inline mitigation through Cloud WAF and WAF Gateway.
• Specification-based shift-left testing: Scans an uploaded API specification file for posture gaps, design flaws, and configuration weaknesses, classifies each issue by severity, and returns developer-ready fixes with CI/CD annotations.
• Bot protection integration: Works with Imperva Advanced Bot Protection to surface sensitive APIs and mitigate automated abuse through bot policies.
• Flexible deployment: Cloud-managed or self-managed operation with agent-based or agentless setups, covering cloud WAF, microservices, encrypted applications, and network-layer monitoring.
• Gateway integrations: Connects with Kong, MuleSoft, Azure APIM, Apigee, and F5 to inspect API traffic through existing gateways, proxies, and load balancers.

Limitations (as reported by users on PeerSpot; reviews cover the wider Imperva Application Security Platform):

• Report creation: Building reports is described as time-consuming compared with other tools, since many elements have to be assembled manually.
• Dashboard and interface: Users asked for a more interactive setup wizard and clearer main dashboard views for traffic counts and alerts.
• On-premises coverage: API security capabilities are weighted toward cloud deployment, which is a constraint for organizations that require fully on-premises operation.
• Support responsiveness: Response times from support were reported to run into several hours for some issues.
• False positives: Some tuning was needed to reduce false positives, though reviewers attributed part of this to their own configuration.

Source: Imperva

8. Cequence Security

Best for: API posture management, testing, and inline attack blocking

Strengths: 250+ risk rules, test plan generation, native bot mitigation

Things to consider: Inline architecture can add latency in large environments

Cequence API Security discovers, monitors, and tests APIs, then assesses them for risks that can lead to compliance or governance issues, data loss, and business disruption. Discovery combines inside-out and outside-in methods and covers internal, external, and third-party APIs as well as edge, gateway, and hosting infrastructure.

The product integrates directly with existing API gateways or deploys inline. Testing, sensitive data handling, and attack mitigation sit in the same platform, with bot mitigation handled natively rather than through a separate enforcement point.

Key features include:

• Discovery and inventory: Identifies documented, undocumented, third-party, and shadow API endpoints to create a runtime API catalog, and generates API specifications automatically when none are available.
• Integrated security testing: Tests APIs in pre-production and at runtime, with test plans generated automatically from Postman collections or API specifications, and support for CI/CD pipelines, IDEs, and standalone testing.
• Compliance risk rules: Ships more than 250 pre-built risk rules mapped to 25 global frameworks, including every version of the OWASP API Security Top 10, PCI DSS, GDPR, HIPAA, SOC 2, ISO 27001, and NIST CSF.
• Audit reporting: Generates reports from live data in one click, mapping findings to each framework’s controls, scoring risk by control area, and attaching remediation guidance for every gap.
• Sensitive data detection and masking: Uses ML-based rules with predefined and customizable data patterns to identify and mask sensitive data, with pattern support across regions.
• Attack mitigation: ML-powered threat detection and analytics work with third-party WAFs and API gateways, while bot management provides native blocking, logging, rate limiting, header injection, and deception.
• AI assistant and MCP tooling: A built-in assistant answers questions about the API estate and returns ranked, evidence-backed findings, and platform capabilities are exposed as MCP tools with human approval required for write actions.

Limitations (as reported by users on PeerSpot):

• Latency in large deployments: The inline component holds traffic while inspecting it, and latency can become a significant issue in bigger environments.
• Traffic mirroring sensor: The sensor used for mirroring traffic was described as outdated and not working properly.
• Cost: Reviewers described the product as expensive, and on-premises deployments carry significant infrastructure costs as they scale.
• Behavioral analysis maturity: Reviewers asked for faster development of the machine learning models to keep pace with attackers who imitate legitimate user behavior.
• Support materials and coverage: Documentation and enablement materials are largely English-only, and the customer success team was described as stretched.

Source: Cequence

If you’re evaluating these same providers specifically against compliance requirements (GDPR, PCI DSS, HIPAA, or SOC 2) see our guide to evaluating API security solutions for compliance, which compares many of the same vendors through that specific lens. 

How to Choose API Security Testing Solutions for REST, GraphQL, and SOAP 

Choosing an API security testing solution requires more than comparing vulnerability scanners. Organizations should evaluate how well each solution discovers APIs, covers different protocols, integrates static and dynamic testing, and fits into existing development workflows. The goal is to maintain visibility and security throughout the API lifecycle, from source code and documentation to runtime testing.

Key considerations include:

• Match the testing approach to the API estate: Start by identifying which API technologies, deployment models, and development practices the organization uses. A REST-heavy environment may benefit from OpenAPI-driven scanning and endpoint testing, while GraphQL requires query-aware analysis and SOAP requires XML and WS-Security testing.
• Decide between self-service testing and pentesting as a service: Determine whether internal teams need a platform they can run continuously or expert-led testing performed as a managed service. Self-service tools are better suited to frequent development and CI/CD testing, but require internal expertise to configure, operate, and interpret results. Pentesting as a service can provide deeper manual validation and business-logic testing by security specialists, but is typically performed less continuously. 
• Verify REST, GraphQL, SOAP and specification coverage: Confirm protocol support at the feature level rather than relying on a general claim of API testing. For REST, check support for HTTP methods, JSON payloads, and OpenAPI specifications. GraphQL coverage should include queries, mutations, variables, introspection, batching, and query complexity. SOAP testing should understand WSDL, XML schemas, SOAP envelopes, and relevant WS-* standards.
• Evaluate authentication, authorization and business-logic testing: Determine whether the solution can test authenticated APIs using the mechanisms your applications rely on, such as OAuth 2.0, API keys, JWTs, sessions, or WS-Security. It should support multiple identities and roles to detect object-level and function-level authorization failures. For business logic, assess whether it can model multi-step workflows and manipulate state, identifiers, values, and operation sequences.
• Assess API discovery and inventory: Look for the ability to identify documented, undocumented, legacy, and shadow APIs across relevant environments. Discovery may use API specifications, application traffic, source repositories, gateways, or infrastructure data. The resulting inventory should track endpoints, versions, ownership, exposure, authentication requirements, and sensitive-data handling so teams can prioritize testing based on risk.
• Evaluate developer and CI/CD integration: Security testing should fit existing development processes without requiring separate manual workflows for every release. Check integrations with source control, build systems, CI/CD platforms, and issue trackers. The solution should support automated test triggers, configurable security gates, reproducible findings, and retesting after remediation while allowing teams to balance scan depth against pipeline execution time.
• Assess enterprise scalability, governance and operational overhead: Evaluate whether the platform can handle the number of APIs, applications, environments, and teams the organization needs to protect. Enterprise features may include role-based access, centralized policies, audit logs, reporting, asset ownership, and integrations with security platforms. Also consider deployment requirements, tuning effort, false-positive management, maintenance, and the expertise needed to operate the solution effectively.

Conclusion

Selecting the right API security strategy is essential for protecting modern application environments across REST, GraphQL, and SOAP architectures. By aligning discovery, vulnerability testing, and runtime protections with organizational workflows, security teams can effectively mitigate risks without hindering developer productivity. A balanced approach ensures comprehensive visibility, robust defense, and sustained development velocity as your software portfolio evolves.