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 your API during development for both security vulnerabilities and conformance to the API Design, and protect your runtime APIs from all sides with the 42Crunch micro-API firewall API Protect.
OWASP API Security Top 10 Vulnerabilities: 2023
API 01: 2023
42Crunch Approach
Broken Object Level Authorization - BOLA
Starting with a valid and secure OpenAPI contract you can build BOLA test configurations and execute them as part of the API Scan. Continuously running specific BOLA tests as part of your CICD pipeline prevents vulnerable APIs from proceeding to production.
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.
42Crunch Platform Capabilities that support the OWASP recommendations
Using API Audit, API Scan and Security Quality Gates, 42Crunch supports the following OWASP recommended security practices to prevent BOLA vulnerabilities:
- Test and evaluate the vulnerability of your authorization mechanism.
- Do not deploy changes that make the tests fail.
- Enforce random and unpredictable GUID values for resource IDs.
- Break the CI build if you find BOLA vulnerabilities.
API 02: 2023
42Crunch Approach
Broken Authentication
- Flag weak/missing authentication schemes as well as weak transport settings inside the OpenAPI contract.
- Run a dynamic API scan with injection of incorrect API keys and tokens and no tokens at all.
- Run-time JWT validation according to RFC 8725.
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 a system's ability to identify the client/user, compromises API security overall.
42Crunch Platform Capabilities that support the OWASP recommendations
Using API Audit and API Scan, 42Crunch supports the following OWASP recommended security practices to prevent broken authentication vulnerabilities:
- API Keys should not be used for user authentication.
- Transmit passwords only over TLS or other strong transport.
- Prevent sensitive authentication details, such as auth tokens and passwords in the URL.
- Validate Token authenticity.
- Reject unsigned/weakly signed JWT tokens.
- Validate JWT expiration dates.
- Enforce authentication for access requests by other microservices.
API 03: 2023
42Crunch Approach
Broken Object Property Level Authorization - BOPLA
- Helping developers define secure response and request schemas makes accidental data exposure impossible. 42Crunch validates OpenAPI contracts to ensure secure schemas are defined for all APIs.
- Adding continuous API conformance scans will detect if responses given by the API do not match the OpenAPI contract.
- Our runtime threat protection also enforces the data constraints and blocks invalid requests and responses, preventing hackers from injecting any undefined data and extracting more data than defined.
OWASP Definition
This category combines API 03:2019 Excessive Data Exposure and API 06:2019 Mass Assignment, focusing on the root cause: the lack of or improper authorization validation at the object property level. This leads to information exposure or manipulation by unauthorized parties.
42Crunch Platform Capabilities that support the OWASP recommendations
Using API Audit, API Scan and API Protect, 42Crunch supports the following OWASP recommended security practices to prevent BOPLA vulnerabilities:
- Ensure the API only exposes output properties that a user should have access to.
- Ensure returned data structures are the bare minimum, according to the business/functional requirements for each endpoint.
- Ensure the API only accepts input properties that should be updated by a client.
- Enforce schema-based response validation, to enforce data returned by all API methods.
API 04: 2023
42Crunch Approach
Unrestricted Resource Consumption
- 42Crunch philosophy to take the OpenAPI definition file (formerly Swagger file) or API contract as the single source of truth for API security allows for specific X-addons (at the API or operation level) covering the needs for rate-limiting and spike-arrest controls.
- At runtime, the defined limits are enforced as well as JSON parser protections (payload size, complexity).
OWASP Definition
Satisfying API requests requires resources such as network bandwidth, CPU, memory, and storage. Other resources such as emails/SMS/phone calls or biometrics validation are made available by service providers via API integrations, and paid for per request. Successful attacks can lead to Denial of Service or an increase in operational costs.
42Crunch Platform Capabilities that support the OWASP recommendations
Using API Audit and API Protect, 42Crunch supports the following OWASP recommended security practices to prevent unrestricted resource consumption:
- Enforce a maximum size of data on all incoming parameters and payloads, such as maximum length for strings, maximum number of elements in arrays, and maximum upload file size.
- Implement a limit on how often a client can interact with the API within a defined timeframe.
- Rate limiting should be fine-tuned based on the business needs. Some API endpoints might require stricter policies.
- Limit/throttle how many times or how often a single API client/user can execute a single operation.
- Enforce proper server-side validation for query string and request body parameters, specifically, the one that controls the number of records to be returned in the response.
API 05: 2023
42Crunch Approach
Broken Function Level Authorization - BFLA
- Continuous API conformance scans will detect if operations are executed by the API that do not match the OpenAPI contract.
-
At runtime:
- 42Crunch ensures that only operations (verbs and paths) defined in the OpenAPI contract can be called.
- API operations which are not defined are blocked by default.
- Unknown API endpoints are handled likewise, preventing unknown API endpoints from being called.
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.
42Crunch Platform Capabilities that support the OWASP recommendations
Using API Scan and API Protect, 42Crunch supports the following OWASP recommended security practices to prevent BFLA vulnerabilities:
- Verify that a regular user cannot access administrative endpoints.
- Verify that a user cannot perform sensitive actions that they should not have access to by simply changing the HTTP method (e.g. from GET to DELETE).
- Verify that the API will deny all access by default, requiring explicit grants to specific roles for access to every function.
API 06: 2023
42Crunch Approach
Unrestricted Access to Sensitive Business Flows
- At 42Crunch we believe in proactive API security by identifying and fixing vulnerabilities during development and testing phases.
- Adding chaotic business flow test cases to security testing is a way to reduce the possibility of unexpected API usage, however, you cannot possibly test all permutations.
- Utilising behavior monitoring tools would help to solve this particular issue, but we found the number of false positives makes it hard to identify the harmful ones.
OWASP Definition
APIs vulnerable to this risk expose a business flow - such as buying a ticket, or posting a comment - without compensating for how the functionality could harm the business if used excessively in an automated manner. This doesn't necessarily come from implementation bugs.
42Crunch Platform Capabilities that support the OWASP recommendations
Using API Audit and API Scan, 42Crunch helps reduce the noise-to-find ratio allowing the behavior monitoring tools to be more effective in identifying the harmful attacks.
API 07: 2023
42Crunch Approach
Server Side Request Forgery - SSRF
- For SSRF we recommend scenario testing to assess behavior prior to going into production of a SSRF attack.
- Between the 42Crunch API security testing and runtime threat protection, we validate and sanitize all client-supplied input data.
OWASP Definition
Server-Side Request Forgery (SSRF) flaws can occur when an API is fetching a remote resource without validating the user-supplied URI. This enables an attacker to coerce the application to send a crafted request to an unexpected destination, even when protected by a firewall or a VPN.
42Crunch Platform Capabilities that support the OWASP recommendations
Using API Scan and API Protect, 42Crunch supports the following OWASP recommended security practices to prevent SSRF:
- Enforce allow lists (property patterns) for remote origins users are expected to download resources from (e.g. Google Drive, Gravatar, etc.), URL schemes and ports, and accepted media types for a given functionality.
- Validate all client-supplied input data.
- Do not send raw responses to clients.
API 08: 2023
42Crunch Approach
Security Misconfiguration
- Our Security-by-design approach allows enterprises make security fully part of the API lifecycle, starting at design time.
- 42Crunch API security testing flags unsecure transport configuration and automatically validates standard headers (such as Content-Type) within the OpenAPI contract.
-
At runtime you should validate headers and content to conform with the OpenAPI contract defining the API.
Anything that does not conform should be either removed (headers) or blocked completely (content).
OWASP Definition
APIs and the systems supporting them typically contain complex configurations, meant to make APIs more customizable. Software and DevOps engineers can miss these configurations, or don't follow security best practices when it comes to configuration, opening the door for different types of attacks.
42Crunch Platform Capabilities that support the OWASP recommendations
Using API Audit and API Protect, 42Crunch supports the following OWASP recommended security practices to prevent security misconfiguration:
- Enforce TLS for all API communications from the client to the API server, regardless of whether it is an internal or public-facing API.
- Enforce specifically which HTTP verbs each API can be accessed by: all other HTTP verbs should be disabled (e.g. HEAD).
- Enforce applicable security headers as a requirement from clients.
- Enforce acceptable incoming content types/data formats that meet the business/ functional requirements.
- Enforce all API response payload schemas, including error responses, to prevent exception traces and other valuable information from being returned to attackers.
API 09: 2023
42Crunch Approach
Improper Inventory Management
- 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 your dashboard of choice, providing instant visibility to security and dev teams. This is even more critical in companies where APIs are implemented across various technologies and global visibility/governance across those technologies is challenging.
- At runtime, unknown paths and API 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.
OWASP Definition
APIs tend to expose more endpoints than traditional web applications, making proper and updated documentation highly important. A proper inventory of hosts and deployed API versions also are important to mitigate issues such as deprecated API versions and exposed debug endpoints.
42Crunch Platform Capabilities that support the OWASP recommendations
Using CI/CD integrations, Security Quality Gates and API Protect, 42Crunch supports the following OWASP recommended security practices to prevent improper inventory management:
- Document all aspects of your API such as authentication, errors, redirects, rate limiting, and endpoints, including their parameters, requests, and responses.
- Discover APIs from untracked OpenAPI documentation.
- Discover and track undocumented API operations.
- Discover and track undocumented API endpoints.
- Block all traffic for undocumented APIs.
- Block all traffic for retired APIs.
API 10: 2023
42Crunch Approach
Unsafe Consumption of APIs
- As a consumer of third-party APIs you can implement the same measures for API security posture and API risk management as you would for your own APIs.
- Continuously validate the quality of the OpenAPI contract that describes the API you want to use.
- If it does not conform to your security standards you either ask the third-party API provider to improve their security posture or change the API provider.
OWASP Definition
Developers tend to trust data received from third-party APIs more than user input, and so tend to adopt weaker security standards. In order to compromise APIs, attackers go after integrated third-party services instead of trying to compromise the target API directly.
42Crunch Platform Capabilities that support the OWASP recommendations
Using API Audit and Security Quality Gates, 42Crunch supports the following OWASP recommended security practices to prevent unsafe consumption of APIs:
- When evaluating service providers, assess their API security posture by the maturity of the OpenAPI definition.
- Ensure all API interactions happen over a secure communication channel (TLS).
- Always validate data received from integrated APIs before using it.
- Maintain an allowlist of well-known locations integrated APIs may redirect yours to: do not blindly follow redirects.
OWASP API Security Top 10 Vulnerabilities: 2019
API 3:2019 - Excessive Data Exposure
API 01: 2019
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: 2019
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: 2019
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: 2019
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: 2019
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: 2019
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: 2019
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: 2019
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: 2019
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: 2019
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.
Secure Your APIs Today
#1 API security platform