OWASP API Security Top 10 Protection

Learn how 42Crunch can protect you against the most common API security threats.
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 API Audit, utilize API Scan to test live endpoints, and protect your APIs from all sides with the 42Crunch micro-API firewall API Protect. Learn more about how each tool in the 42Crunch API Security Platform can protect you from the most common API security vulnerabilities.

API1:

Broken Object Level Authorization

API SECURITY AUDIT
(Deployment / Test)
  • Leverage Enterprise Data Dictionary to highlight potential exposure*
  • Detect simplistic identifiers*

CONFORMANCE SCAN (Deployment/Test)
  • Generate automated BOLA scenarios*
  • Test API resilience against BOLA/IDOR hacking techniques*

API MICRO-FIREWALL
(Runtime)
  • Integration with fine-grained
    authorization systems like OPA
  • ID virtualization policies

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 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. *Roadmap.

API2:

Broken User Authentication

API SECURITY AUDIT
(Deployment / Test)
  • Flag weak/missing authentication schemes as well as weak transport settings

CONFORMANCE SCAN (Deployment/Test)
  • Injection of incorrect API keys and tokens*

API MICRO-FIREWALL
(Runtime)
  • JWT Validation according to RFC 8725
  • Access tokens/API keys validation from API Contract

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.

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

API SECURITY AUDIT
(Deployment / Test)
  • Flag non-compliant response schemas
  • Flag missing error codes and/or schemas

CONFORMANCE SCAN (Deployment/Test)
  • Test schemas compliance

API MICRO-FIREWALL
(Runtime)
  • Blocks responses which do not match the schemas

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.

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

API SECURITY AUDIT
(Deployment / Test)
  • Flag data missing constraints (min/max size)
  • Flag operations that do not declare 429 responses

CONFORMANCE SCAN (Deployment/Test)
  • Test data constraints

API MICRO-FIREWALL
(Runtime)
  • Rate Limiting by API and by operation
  • Blocks overflow type attacks
  • JSON Parser protection

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 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

API SECURITY AUDIT
(Deployment / Test)
  • Automated audit to discover APIs
  • Flag missing/invalid OAuth scopes

CONFORMANCE SCAN (Deployment/Test)
  • Test how API handles unknown requests (verbs, paths, data)

API MICRO-FIREWALL
(Runtime)
  • Block requests with unexpected verbs and paths/subpaths (including path traversal attacks)
  • Blocks unknown APIs requests

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 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

API SECURITY AUDIT
(Deployment / Test)
  • Flag non-compliant request schemas

CONFORMANCE SCAN (Deployment/Test)
  • Test schemas compliance

API MICRO-FIREWALL
(Runtime)
  • Blocks requests which do not match schemas

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.

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

API SECURITY AUDIT
(Deployment / Test)
  • Audit is used to discover potential issues early in lifecycle and is automated for security governance

CONFORMANCE SCAN (Deployment/Test)
  • Tests automatically for API implementation security issues at early development stages

API MICRO-FIREWALL
(Runtime)
  • Secure TLS configuration
  • Blocks by default
  • Safe error messages
  • Automatic injection of security headers
  • Automatic enforcement of API contract

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.

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

API SECURITY AUDIT
(Deployment / Test)
  • Flags loose schemas and data
    definitions (headers, query and path params)

CONFORMANCE SCAN (Deployment/Test)
  • Tests resistance to bad data formats and invalid data types

API MICRO-FIREWALL
(Runtime)
  • Protect from injections through validation of all data against API contract

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.

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

API SECURITY AUDIT
(Deployment / Test)
  • 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

CONFORMANCE SCAN (Deployment/Test)
  • Tests for unknown verbs
  • Detects unknown responses

API MICRO-FIREWALL
(Runtime)
  • Unknown traffic is blocked by default
  • Non-blocking mode can be enabled for discovery/monitoring

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 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

API SECURITY AUDIT
(Deployment / Test)

N/A

CONFORMANCE SCAN (Deployment/Test)

N/A

API MICRO-FIREWALL
(Runtime)
  • All traffic is monitored and logged
  • Integration with enterprises logging infrastructure
  • Integration with SIEM

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.

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.

Webinar

OWASP API Security Top 10 

Find, Fix and Secure your APIs

Speaker Philippe Deryck

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.