42Crunch maps every OWASP API Security Top 10 (2023) risk to a specific control in the Contract → Audit → Scan → Protect cycle, so gaps get caught before ship — not after a breach.
42Crunch's API Security platform is a set of automated tools that keep APIs secure from design through production: API Audit tests the OpenAPI contract at design time, API Scan dynamically tests the running implementation during development and in CI/CD, and API Protection enforces the approved contract as a runtime micro-firewall. Together, they give continuous coverage against every category in the OWASP API Security Top 10 — not a one-time audit that goes stale the day after it's run.
An endpoint exposes an object identifier — a user ID, an order ID, a record ID — and fails to check that the caller actually has permission to access that specific object. Change the ID in the request and you're looking at someone else's data.
Object-level authorization tested automatically in API Scan, with CI/CD gates blocking vulnerable APIs before they reach production.
Weaknesses in how an API verifies who's calling it — missing rate limits on login, permissive password rules, insecure token issuance or validation, credentials leaking into logs — that let an attacker impersonate a legitimate user or skip authentication entirely.
OpenAPI contracts flagged for weak or missing auth schemes; dynamic scans probe with bad tokens and credentials; runtime JWT validation per RFC 8725.
Even when access to an object itself is properly checked, individual properties inside it may not be — letting a user read fields they shouldn't see, or write to fields (like a role or a balance) they should never be able to change.
Secure request/response schemas enforced at design time, continuously re-scanned for drift, with runtime blocking of anything the contract doesn't declare.
An API that doesn't cap how much a client can ask for — response size, record counts, execution time, concurrent operations — can be run up in cost or overwhelmed outright, whether by a deliberate attack or just uncontrolled usage.
Rate limits and payload constraints defined in the OpenAPI contract and enforced at runtime, with JSON-parser protections against oversized or overly complex payloads.
Complex role and permission hierarchies make it easy to leave an administrative or privileged operation reachable by users who should only have standard access — an authorization gap at the level of the function itself, not the data it touches.
Runtime allows only contract-defined operations to execute — undefined operations and unknown endpoints are blocked by default.
Every technical control can be correctly enforced and a business process — buying limited-stock items, posting reviews, opening accounts — can still be abused if nothing limits how it's invoked, letting automation exploit it at a speed or scale no real user could match.
Chaotic business-flow test cases run during Audit and Scan, cutting the noise so behavior-monitoring tools can spot abuse patterns faster.
An API that fetches a remote resource using a URL the client supplied — without validating where that URL actually points — can be tricked into making requests to internal infrastructure or unintended external services on the attacker's behalf.
Scenario testing validates behavior before production; runtime sanitizes and validates every client-supplied input.
Small gaps accumulate: unnecessary features left enabled, missing security headers, verbose error messages, overly permissive CORS, outdated components. Individually minor, collectively they widen the attack surface considerably.
Security built into the contract from design — enforced transport, headers, verbs, and content types, validated continuously at runtime.
APIs multiply faster than documentation keeps up — old versions, staging endpoints, and undocumented integrations stay reachable long after anyone is actively tracking them, each one a live attack surface sitting outside the team's inventory.
Continuous discovery finds undocumented APIs in code repos and at runtime; undocumented and retired APIs get blocked by default.
Developers tend to trust data coming back from third-party and partner APIs more than user input — applying weaker validation and following redirects without question — turning a flaw in a service you don't control into one in the service you do.
The same contract-driven standard applied to third-party APIs your service consumes — not just the ones you publish.
Also covers the OWASP API Security Top 10: 2019 edition, mapped the same way.
Static analysis of the OpenAPI contract at design time — 300+ automated checks, scored instantly in your IDE.
Dynamic testing against the running API with simulated real traffic, mapped directly to the OWASP API Top 10.
The approved contract becomes the runtime enforcement policy — a positive security model, not a blocklist.
A community-maintained list of the ten most critical API security risks, published by OWASP — the same standard reference the wider AppSec industry uses to prioritize API vulnerabilities. 42Crunch tracks both the 2023 and 2019 editions.
Each category maps to a specific control across Audit, Scan, and Protection — some caught at design time in the contract, some caught dynamically in testing, and some enforced continuously at runtime. No single stage covers every category alone; the three together do.
No — it complements one. A generic WAF or gateway inspects traffic against generic rule sets; 42Crunch's runtime protection enforces your specific OpenAPI contract as a positive security model, catching what a generic ruleset is never specific enough to know is wrong.
Automatic. Coverage is generated directly from your OpenAPI contract — there's no separate rule set to write or maintain by hand.
Yes. Findings are mapped to both editions, so teams that still report against the 2019 list and teams that have moved to 2023 both get accurate, current coverage.
Point 42Crunch at your OpenAPI contract and see exactly where you stand against all ten categories — no agent install, no commitment required.