OWASP API Security Top 10 Protection

Learn how 42Crunch can protect you against the most common API security threats.

Upcoming Webinar:  API Security Today and OWASP API Security Top 10 Challenges
More Details

Protect your APIs from the most common API vulnerabilities with 42Crunch.

The 42Crunch API Security Platform is a set of automated tools that ensure your APIs are secure from design to production. You can initiate the API security process at design time with the API Security Audit, utilize the Conformance Scan to test live endpoints, and protect your APIs from all sides with the 42Crunch micro-API Firewall. Learn how more about how each tool in the 42Crunch API Security Platform can protect you from the most common API security vulnerabilities.

API Security Audit  
(Deployment / Test)
Conformance Scan 
(Deployment / Test)
API Micro-Firewall
API1 : Broken Object Level Authorization
  • Leverage Enterprise Data Dictionary to highlight potential exposure*
  • Detect simplistic identifiers*
  • Generate automated BOLA scenarios*
  • Test API resilience against BOLA/IDOR hacking techniques*
  • Integration with fine-grained
    authorization systems like OPA
  • ID virtualization policies
API2 : Broken User Authentication
  • Flag weak/missing authentication schemes as well as weak transport settings 
  • Injection of incorrect API keys and tokens* 
  • JWT Validation according to RFC 8725
  • Access tokens/API keys validation from API Contract 
API3 : Excessive Data Exposure
  • Flag non-compliant response schemas 
  • Flag missing error codes and/or schemas 
  • Test schemas compliance 
  • Blocks responses which do not match the schemas 
API4 : Lack of Resources & Rate Limiting
  • Flag data missing constraints (min/max size) 
  • Flag operations that do not declare 429 responses 
  • Test data constraints 
  • Rate Limiting by API and by operation
  • Blocks overflow type attacks 
  • JSON Parser protection 
API5 : Broken Function Level Authorization
  • Automated audit to discover APIs 
  • Flag missing/invalid OAuth scopes 
  • Test how API handles unknown requests (verbs, paths, data) 
  • Block requests with unexpected verbs and paths/subpaths (including path traversal attacks)
  • Blocks unknown APIs requests 
API6 : Mass Assignment
  • Flag non-compliant request schemas 
  • Test schemas compliance 
  • Blocks requests which do not match schemas 
API7 : Security Misconfiguration
  • Audit is used to discover potential issues early in lifecycle and is
    automated for security governance 
  • Tests automatically for API implementation security issues at early development stages 
  • Secure TLS configuration
  • Blocks by default 
  • Safe error messages 
  • Automatic injection of security headers 
  • Automatic enforcement of API contract 
API8 : Injection
  • Flags loose schemas and data
    definitions (headers, query and path params) 
  • Tests resistance to bad data formats and invalid data types 
  • Protect from injections through validation of all data against API contract 
API9 : Improper Assets Management
  • Integration of audit with CI/CD pipeline
    for automatic discovery of APIs
  • Single pane of glass view of all APIs
    security status across the enterprise 
  • Tests for unknown verbs  
  • Detects unknown responses
  • Unknown traffic is blocked by default
  • Non-blocking mode can be enabled for discovery/monitoring 
API10 : Insufficient Logging & Monitoring
  • All traffic is monitored and logged
  • Integration with enterprises logging infrastructure 
  • Integration with SIEM 


API1 : Broken Object Level Authorization

APIs tend to expose endpoints that handle object identifiers, creating a wide attack surface Level Access Control issue. Object level authorization checks should be considered in every function that accesses a data source using an input from the user.

The 42Crunch Approach

BOLA is also known as IDOR and is triggered by guessable IDs and lack of authorization checks at resources level. We can integrate via our protections with external authorization systems, acting as an enforcement point. Additionally, we will introduce in Q3 two approaches to address the guessable IDs problem, through dedicated protection extensions: (1) Replace internal IDs by UUIDs on the fly: when IDs are returned by the back end, they are replaced by a UUID. This allows users to introduce non-guessable IDs with no need to change the APIs implementation. (2) Track IDs by session: only IDs that have been returned by the API within a session can be used in subsequent calls. 

API2 : Broken User Authentication

Authentication mechanisms are often implemented incorrectly, allowing attackers to compromise authentication tokens or to exploit implementation flaws to assume other user’s identities temporarily or permanently. Compromising system’s ability to identify the client/user, compromises API security overall.

The 42Crunch Approach

Authentication is first enforced at design time: APIs with weak authentication schemes according to their risk level will be caught by the audit rules. Such APIs can be prevented from deployment in your CI/CD pipeline.

OAuth2 authorization servers endpoints (auth and token endpoints) can be protected to only allow specific grant types, enforce scopes values and access token validity time, making sure that consumers cannot use client_credentials for example or enforce that a state is used with the authorization code grant, preventing attacks like this one.

Additionally, our runtime protection policies validate JWT according to the RFC 8725, published in Feb 2020, preventing attacks listed in that RFC.

We are also working on supporting the FAPI security profiles https://openid.net/wg/fapi/ with pre-built protections.

API3 : Excessive Data Exposure

Looking forward to generic implementations, developers tend to expose all object properties without considering their individual sensitivity, relying on clients to perform the data filtering before displaying it to the user.

The 42Crunch Approach

Helping developers to define response schema and follow them makes accidental data exposure impossible 42Crunch enforces control at development and build time to ensure strong schemas are defined for all APIs. More than 300 controls are done as part of the audit. Missing response codes are also flagged (401, 403, 404, 415, 500). 

At QA / testing time, the conformance scan will detect if responses given by the API do not match the contract. 

The 42Crunch firewall will block responses that do not match the schemas. When a response is invalid, the existing payload is replaced with a generic error, preventing exception leakage and/or verbose error leakage. Responses with unknown error codes are also blocked. 

Those services are highly complementary: if the schemas are loose, validation works all the time. So runtime support of OAS/schemas validation is not enough, you must ensure the schemas are well-defined first.

API4 : Lack of Resources & Rate Limiting

Quite often, APIs do not impose any restrictions on the size or number of resources that can be requested by the client/user. Not only can this impact the API server performance, leading to Denial of Service (DoS), but also leaves the door open to authentication flaws such as brute force.

The 42Crunch Approach

42Crunch audit validation rules flags loose definitions and will guide the developers to add constraints to string sizes, integer sizes and array sizes, limiting exposure to various overflow attacks. The audit also raises an issue when an API does not define 429 error codes for rate limiting. 

At conformance scan time, constraints are validated by sending data outside of limits and analyzing the API response. 

Finally, at runtime the expected limits are enforced. Rate limiting protections can be added to the OAS file (at the API or operation level) as well as JSON parser protections (payload size, complexity). 

API5 : Broken Function Level Authorization

Complex access control policies with different hierarchies, groups, and roles, and an unclear separation between administrative and regular functions, tend to lead to authorization flaws. By exploiting these issues, attackers gain access to other users’ resources and/or administrative functions.

The 42Crunch Approach

At runtime, 42Crunch ensures that only verbs and paths defined in the OAS-based contract can be called. APIs which are not defined are blocked as well, preventing unknown APIs from being called. 

Additionally, at design time, customers can use our audit discovery mechanisms via CI/CD to uncover shadow APIs and automatically audit and report them.

API6 : Mass Assignment

Binding client provided data (e.g., JSON) to data models, without proper properties filtering based on an allowlist, usually lead to Mass Assignment. Either guessing objects properties, exploring other API endpoints, reading the documentation, or providing additional object properties in request payloads, allows attackers to modify object properties they are not supposed to.

The 42Crunch Approach

Similarly to API3, audit also analyzes requests schemas/forms flagging missing constraints and patterns, as well as headers, path and queries params. 

At runtime, the 42Crunch enforces the data constraints and blocks invalid requests, preventing hackers from injecting any undefined data or calling unknown path and verbs. 

API7 : Security Misconfiguration

Security misconfiguration is commonly a result of unsecure default configurations, incomplete or ad-hoc configurations, open cloud storage, misconfigured HTTP headers, unnecessary HTTP methods, permissive Cross-Origin resource sharing (CORS), and verbose error messages containing sensitive information.

The 42Crunch Approach

Our security as code approach allows enterprises to make security fully part of the API lifecycle, starting at design time. 42Crunch API Security Audit flags unsecure transport configuration and automatically validates standard headers (such as Content-Type) within the OAS definition.

The 42Crunch runtime only accepts secure connections, supports MTLS inbound/outbound and only accepts TLS1.2 with strong cipher suites. Standard protections include CORS support and automatic injection of security headers. Our API firewall is constantly kept up to date for latest CVEs and checked for security vulnerabilities.

The API firewall runtime is very small and can be deployed for all APIs, with very limited impact to performance. Since the configuration only depends on the OAS file, firewalls can be put in place early in all environments, including development, limiting the possibility to inject security issues in early lifecycle phases.

Error messages which do not match the expected formats are blocked and replaced with standard ones which do not give away internal information.

API8 : Injection

Injection flaws, such as SQL, NoSQL, Command Injection, etc., occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s malicious data can trick the interpreter into executing unintended commands or accessing data without proper authorization.

The 42Crunch Approach

Injections hit APIs via unsanitized inputs. By forcing the companies to define tightened input schemas and patterns, 42Crunch eliminates the risk of arbitrary payloads hitting the backend. 

Additionally to the standard OAS based allowlist, customers can deploy denylist-based protections for properties where a precise regex is not an option. 

API9 : Improper Assets Management

APIs tend to expose more endpoints than traditional web applications, making proper and updated documentation highly important. Proper hosts and deployed API versions inventory also play an important role to mitigate issues such as deprecated API versions and exposed debug endpoints.

The 42Crunch Approach

42Crunch CI/CD integration is core to addressing this issue: by providing a security point of control whenever code is pushed to the platform and by delivering a discovery mechanism that leaves no room for unknown APIs in any code repository. All discovered APIs can be viewed in our dashboard, or in your dashboard of choice, providing instant visibility to security and dev teams alike. This is even more critical in companies where APIs are implemented across various technologies and where global visibility/governance across those technologies is challenging. 

At runtime, unknown paths and APIs traffic will be blocked by default. The firewall listening only mode will allow you to record invalid traffic, without blocking it, and discover unwanted/forgotten traffic.  

API10 : Insufficient Logging & Monitoring

Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack systems, maintain persistence, pivot to more systems to tamper with, extract, or destroy data. Most breach studies demonstrate the time to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring.

The 42Crunch Approach

All transactions flowing through the API Firewall (successful or blocked) are recorded and can be leveraged via our platform or via the customers logging/monitoring platform of choice. Attack information can be pushed to SIEM using Common Event Format or JSON for correlation and incident response. Incidents are also visible in our platform real-time security dashboard. 

OWASP API Security Top 10 Webinars

Check out our OWASP webinar series for tips and tricks on how to 
protect yourself from the OWASP API Security Top 10

Tips & Tricks for Protecting Yourself Against the OWASP API Security Top 10

Go to webinar page

OWASP API Threat Protection with the 42Crunch API Security Platform (Part 1)

Go to webinar page

OWASP API Threat Protection with the 42Crunch API Security Platform (Part 2)

Go to webinar page

42Crunch OWASP API Top 10 Solutions Matrix

Download our solutions matrix for a full view of how 42Crunch addresses each of the OWASP API Security Top 10.

Download Now


Want to learn more? Here are some resources to help you out!

Free Tools

Looking to make OpenAPI / Swagger editing easier in VS Code? Or want to check how secure your API is? Check out our free tools.

Get Started

#1 API Security Community

Join your security peers and get the industry’s leading API security newsletter every week.

Learn More

Platform Tutorials

Ready to get started? We have some short video tutorials for audit, scan and protection to help get you up and running as fast as possible.

Get Started

Ready to Get Started?

Developer-first solution for delivering API security as code.