OWASP API Security Top 10 Protection
Learn how 42Crunch can protect you against the most common API security risks and threats. The 42Crunch API Security Platform is a set of automated API tools that ensure your APIs are secure from design to production. You can initiate API security testing at design time with API Audit, utilize API Scan to test live endpoints, and protect your runtime APIs from all sides with the 42Crunch micro-API firewall API Protect.
API 01:
42Crunch Approach
Broken Object Level Authorization
(API Audit)
- 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
OWASP Definition
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.
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 have added 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.
API 02:
42Crunch Approach
Broken User Authorization
(API Audit)
- 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
OWASP Definition
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.
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 API security breach.
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.
API 03:
42Crunch Approach
Excessive Data Exposure
(API Audit)
- Flag non-compliant response schemas
- Flag missing error codes and/or schemas
- Test schemas compliance
- Blocks responses which do not match the schemas
OWASP Definition
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.
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 API audit. Missing response codes are also flagged (401, 403, 404, 415, 500).
At QA / testing time, the API conformance scan will detect if responses given by the API do not match the OpenAPI contract.
The 42Crunch API 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.
API 04:
42Crunch Approach
Lack of Resources & Rate Limiting
(API Audit)
- 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
OWASP Definition
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.
42Crunch API audit validation rules flag 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).
API 05:
42Crunch Approach
Broken Function Level Authorization
(API Audit)
- 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
OWASP Definition
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.
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.
API 06:
42Crunch Approach
Mass Assignment
(API Audit)
- Flag non-compliant request schemas
- Test schemas compliance
- Blocks requests which do not match schemas
OWASP Definition
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.
Similarly to API3, API Linter also analyzes requests schemas/forms flagging missing constraints and patterns, as well as headers, path and query parameters.
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.
API 07:
42Crunch Approach
Security Misconfiguration
(API Audit)
- 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
OWASP Definition
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.
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.
API 08:
42Crunch Approach
Injection
(API Audit)
- 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
OWASP Definition
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.
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.
API 09:
42Crunch Approach
Improper Assets Management
(API Audit)
- 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
OWASP Definition
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.
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.
API 10:
42Crunch Approach
Insufficient Logging & Monitoring
(API Audit)
N/A
N/A
- All traffic is monitored and logged
- Integration with enterprises logging infrastructure
- Integration with SIEM
OWASP Definition
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.
All transactions flowing through the API Protect (successful or blocked) are recorded and can be leveraged via our API Security 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's real-time security dashboard.
Dr. Philippe De Ryck
Dr. Philippe De Ryck, Web Security Expert with Pragmatic Web Security and Colin Domoney of 42Crunch and APISecurity.io, take a deep dive into understanding and addressing the OWASP API Security Top 10 issues.
Ready to Learn More?
Developer-first solution for delivering API security as code.