OWASP Top 10 project has for a long time been the standard list of top vulnerabilities to look for and mitigate in the world of web applications. APIs represent a significantly different set of threats, attack vectors, and security best practices. This caused the OWASP community to launch OWASP API Security project in 2019. Don’t worry, we’ve got your back!
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 will introduce in Q3 two approaches to address the guessable IDs problem, through dedicated protection extensions:
– 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.
– Track IDs by session: only IDs that have been returned by the API within a session can be used in subsequent calls.
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 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.
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 150 controls are done as part of the audit, documented here. 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.
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 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).
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.
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, 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.
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.
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.
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.
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 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.
Want to learn more? Here are some resources to help you out!
Looking to make OpenAPI editing easier in VS Code? Or want to check how secure your API is? Check out our free tools.
Information on the risks, guidelines, and fixes relating to the OpenAPI Specification. Both OAS v2 and v3 are available!
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.