OWASP API Top 10 Risks Can’t Be Blocked, But They Can Be Fixed

A question Cequence frequently hears from security teams just beginning their API security program journey is “how do we block OWASP API Top 10 issues?” – but that’s not the right question. It’s an understandable assumption. After all, security teams are trained to think in terms of detection and blocking – stop the bad traffic, deny the malicious requests, protect the perimeter. But here’s the fundamental problem: OWASP API Security Top 10 findings are vulnerabilities, not attacks. Vulnerabilities can’t be blocked, so they need to be ultimately addressed in the application code by development. It is possible to block some of the attacks against these vulnerabilities before the malicious traffic is routed to the application, but ultimately the API code must be improved to eliminate the vulnerability to fully eliminate the risk.

You Can’t Block a Design or Implementation Flaw

Let’s get specific. How exactly would you “block” Broken Object Level Authorization (API1)? This vulnerability means an API doesn’t properly verify that a user should have access to the specific object they’re requesting. It’s a flaw in authorization logic. There’s no malicious signature to detect, no bad actor to deny. The vulnerability is the way your API works.

The same applies across the OWASP API Top 10:

• Broken Authentication (API2): The authorization implementation is flawed.
• Broken Object Property Level Authorization (API3): The API returns more data than it should.
• Unrestricted Resource Consumption (API4): Proper throttling isn’t implemented.
• Broken Function Level Authorization (API5): Role checks are insufficient resulting in improper authorization controls.

These aren’t threats coming from outside that you can put a firewall in front of. They’re problems inside your code.

The Shadow API Problem Makes This Even More Dangerous

Here’s where the “blocking” mindset really breaks down: What happens when your API security solution discovers OWASP Top 10 vulnerabilities in shadow APIs, or endpoints your team didn’t even know existed? Or in APIs that were marked as deprecated months ago but are still active and handling production traffic?

These scenarios are alarmingly common in enterprise environments:

• A developer spins up a test endpoint that never gets documented
• A legacy API version was supposed to be sunset but still has active consumers
• An internal service gets exposed externally without proper security review
• Microservices proliferate faster than your API catalog can track them

You can’t block these APIs without understanding what they do and who depends on them. Blocking a shadow API might break critical business workflows you didn’t know existed. Blocking a “deprecated” API might take down a revenue-generating integration that nobody remembered to migrate.

The Right Mental Model

Think of OWASP API Top 10 findings the same way you think about OWASP Top 10 web application vulnerabilities or CVEs in your dependencies. API security vulnerabilities work the same way. They’re development issues that require development solutions – whether those APIs are in your official catalog, lurking in the shadows, or still serving traffic despite being marked for deprecation.

The Answer Isn’t Blocking; it’s Remediation and Governance

• Regularly discover your internal, external, and third-party APIs
• Document any shadow API and assign it to an owner
• Properly secure them according to their risk profile
• For deprecated APIs, execute a planned migration and sunset strategy
• Fix the OWASP vulnerabilities before they’re exploited

Attribution and Remediation Workflows

The ideal response to discovering OWASP API Top 10 vulnerabilities is the same as discovering any code-level security issue: fix it in the code and deploy the corrected version.

Here’s what an effective API security workflow looks like:

• Discovery: Your API security solution identifies that an endpoint exposes excessive data (possibly a shadow API or deprecated endpoint)
• Attribution: The platform should enable admins to configure which team or individual owns this API; a crucial step, especially for shadow APIs where ownership may not be immediately clear
• Assignment: The finding is automatically routed to the identified owner with full context about the vulnerability
• Remediation: Developers modify the code to properly filter sensitive fields from the response, or properly deprecate and migrate away from the vulnerable API
• Deployment: The updated API version is pushed through your CI/CD pipeline to production
• Verification: Your security tooling confirms the vulnerability has been resolved

This is fundamentally different from a “detect and block” mindset. You’re not trying to intercept something bad – you’re fixing something broken.

What to Look for in API Security Solutions

When evaluating API security platforms, ask vendors how they support remediation, not just detection:

• Complete API discovery: Does it find shadow APIs and zombie endpoints that were supposed to be deprecated?
• Automated attribution: Does it provide capabilities to associate discovered APIs and their vulnerabilities to the appropriate owners, even for undocumented endpoints?
• Developer integration: Does it create tickets in Jira, ServiceNow, or your existing workflow tools?
• Ownership mapping: Does it integrate with your organizational structure to understand team ownership?
• Actionable guidance: Do developers get clear, contextual information about what needs to be fixed?
• CI/CD integration: Can you catch these issues before they reach production?
• Remediation tracking: Does the platform sync with external ticketing systems such as ServiceNow and Jira to track when vulnerabilities are actually fixed?

Bot Management Can Help

While API security solutions are not designed for blocking, modern bot management products can help, especially one that is integrated closely with API security. Cequence Bot Management uses behavioral analysis to determine intent and couples that with deep understanding of an organization’s APIs and how they work to identify anomalous API transactions and block them. It can identify anomalies such as endpoint enumeration, account takeover (ATO) attempts, sensitive data exposure, and more. Ultimately the API vulnerabilities should be fixed, but Cequence Bot Management can protect the APIs and give the team time to remediate.

The Bottom Line for CISOs

As you evaluate API security solutions, make sure your team understands what they’re actually buying. If a vendor’s pitch centers on blocking OWASP API Top 10 issues, they either don’t understand the problem space or they’re selling you the wrong solution. What you need is a platform that helps you discover all your APIs (known and unknown), identify vulnerabilities, route findings to the appropriate teams, and track remediation to completion.