Who are OWASP?

OWASP (Online Web Application Security Project) is an organisation providing unbiased information and advice surrounding the security of computer and internet applications. They achieve this via operating a number of "projects", each focused on a different remit.

OWASP are perhaps best known for their flagship "OWASP Top 10 Web Application Security Risks" project, commonly known as the "OWASP Top 10". However OWASP acts as an umbrella for dozens of projects, listed at https://owasp.org/projects/ 

What are Application Programming Interfaces (APIs)?

An application programming interface (API) is a type of software interface, offering a service to other pieces of software or computers. In contrast to a user interface such as a typical website user interface, it is not intended to be used directly by a person (the end user). A web API will typically provide service over HTTPS but will accept requests and return responses using a computer-parseable file format such as JSON or XML, rather than the HTML used for human interfaces (such as web sites and applications).

APIs are a critical part of modern mobile, SaaS and web applications and can be found in customer-facing, partner-facing and internal applications.

Are APIs secure?

By nature, APIs often expose application logic and sensitive data such as Personally Identifiable Information (PII) and because of this have increasingly become a target for attackers. They are vulnerable to many of the same issues as human-readable HTML websites, as well as some unique risks of their own.

What is the OWASP API Security Top 10 list?

Every few years the OWASP community come together to review the ten most critical vulnerabilities and security risks relating to Application Programming Interfaces (APIs) by analysing the most important  security risks in real-world web APIs, drawing on vulnerabilities and incidents reported by member and partner organisations of OWASP, and identifying the frequency of occurrence as well as impact of common exploit of these vulnerabilities.

This list is then published at https://owasp.org/www-project-api-security/ and is intended to feed into the production of guidance on concerns, countermeasures and best practices relating to security in this area.

What is an OWASP Top 10 API Security Risk?

It is important to understand that the ten items produced on this list are risks or categories of things that threaten the security of the service and its data from the perspective of the user (data subject) and provider (data owner), within web APIs. That is to say, each item on the list is not an individual vulnerability per se but may represent a type of vulnerability (within an overall taxonomy) that is seen expressed across dozens or hundreds of systems and services in slightly different ways. A single risk on the list may be exploitable via dozens of different attack types, and potentially hundreds of individual vulnerabilities.

For example, as of the 2019 update, one item on the list is simply "security misconfigurations". This covers in reality thousands of types of technical flaws and settings across hundreds of products, services and applications.

Each of these weaknesses or flaws can in turn exist within hundreds of different software systems, many of which will be uncovered in commercial and open source software and be published as CVEs, and many of which will exist in in-house application code and must be checked for from first principles.

Can AppCheck scan web APIs?

Yes, AppCheck can be configured to scan SOAP, REST and GraphQL web APIs. More information on this is available from the following links:

• https://appcheck.zendesk.com/hc/en-us/articles/360002686558-API-Scanning-with-AppCheck
• https://appcheck.zendesk.com/hc/en-us/articles/4404329793041-Setting-Up-An-API-Scan 
• https://appcheck.zendesk.com/hc/en-us/articles/360033469174-Can-the-AppCheck-scanner-scan-SOAP-and-REST-APIs- 

In addition to specifically targetting APIs in the configured scan scope, customers are able to scan front end web applications that make use of a web API for data loading (such as Single Page Applications - SPAs) thanks to its browser-based crawler. However it is worth noting that if the API endpoint is on a different domain to the targeted application (eg api.domain.com) then the "group URLs" option should be enabled in the scan settings, and both domains included in the targets list.

Does AppCheck detect all OWASP Top 10 API Security Risks?

The list below outlines to what extent AppCheck can be leveraged to provide assurance against each of the OWASP Top 10 API Security Risks. It is worth noting that in order to thoroughly scan an API, it is necessary in most cases to "seed" the AppCheck scan configuration with a copy of the relevant WSDL or OpenAPI specification file for the targeted API (a document that provides a "map" of the API, listing available methods and arguments for each etc).

It is important to understand that a vulnerability scanner such as AppCheck must be used appropriately alongside a robust and comprehensive suite of other technical and administrative controls and audit methodologies in order to deliver full assurance against all API risks:

API1:2019 Broken Object Level Authorization

Object level authorization is an access control mechanism that is usually implemented at the code level to validate that one user can only access objects that they should have access to. Every API endpoint that receives an ID of an object, and performs any type of action on the object, should implement object level authorization checks. The checks should validate that the logged-in user does have access to perform the requested action on the requested object. Failures in this mechanism typically leads to unauthorized information disclosure, modification, or destruction of all data.

Object level authorization checks should be considered in every function that accesses a data source using an input from the user. Broken Object Level Authorization (BOLA), often also referred to as Insecure Direct Object Reference (IDOR) happens when an application does not correctly confirm that the user performing the request has the required privileges to access a resource of another user

How AppCheck can help

BOLA/IDOR vulnerabilities are traditionally difficult for automated vulnerability scanners to detect, since they rely on some contextual understanding of which resources are appropriate for a user to be able to access by object ID, and which are not. AppCheck will detect suspected BOLA/IDOR instances, but may report these as "Potential" if it is unable to determine definitively whether the required object should be retrievable by ID or not. Due to the custom nature of applications, AppCheck is unable to rule on whether a given instance of permitted object retrieval discovered is expected behaviour or an unintentional vulnerability, as it lacks context - however it does present this list in its report for review.

API2:2019 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 a system’s ability to identify the client/user, compromises API security overall. This is a broad category covering multiple issues, such as accidentally exposing APIs that are considered "internal" to a public sphere, using weak API keys, including keys or credentials in query strings or other URL parts, not performing access token validation or using unsigned JWTs.

How AppCheck can help

AppCheck will check for many user level authentication issues with APIs, including parsing of API payload responses (eg JSON) for credentials and tokens. It will also look out for weakly implemented authentication, for example long response 302 redirects, which usually happens when the application serves up the content of a restricted view in the response of the page but then sends a redirect in the header. AppCheck will additionally analyse JWT tokens for common security flaws such as the use of the "None" cipher algorithm, and excessive token expiry time.

API3:2019 Excessive Data Exposure

Where an API is being used to perform data functions on behalf of for example a Single Page Application (SPA) front end user interface, then developers can often expose/return all object properties in their responses without considering their individual sensitivity - serving them to the requesting software client, and relying on clients to perform the data filtering before displaying it to the user via an overlaid user interface. Where the entire object is retrievable from the API, sensitive details can be inadvertently exposed by any user who simply analyses the object in its "raw" format within their browsers "Inspector" panel or by querying the API using a tool such as curl to gather the raw response.

How AppCheck can help

AppCheck will check for many data exposure issues with APIs, including parsing of API payload responses (eg JSON) for apparently sensitive information that is likely not intended. AppCheck has specific detection logic for sensitive data, including various PII forms such as given names. Additionally, AppCheck will also report sensitive information disclosed in API responses - such as password hashes, API keys, and session tokens.

API4:2019 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.

How AppCheck can help

AppCheck is careful to balance the requirements on checking rate limiting against customer requirements to not perform volumetric testing that may put a targeted service at risk during scanning. AppCheck contains logic to detect specific known/published brute force weaknesses in detected services, but will not attempt volumetric brute forcing of endpoints during scanning, so as not to put targeted services at risk.

API5:2019 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. Essentially, a vulnerable API may rely on the client to use user level or admin level APIs as appropriate but an attacker who is able to figure out the “hidden” admin API methods and invoke them directly can access functionality that was not intended for them to access. By exploiting these issues, attackers gain access to other users’ resources and/or administrative functions.

How AppCheck can help

AppCheck will detect and report on exposed APIs, services and methods, but customers will need to review these on a case by case basis from a business logic perspective, to determine whether they should be exposed or not.

API6:2019 Mass Assignment

Sometimes an API may bind ALL client-provided data from a request (e.g., JSON) to data models, without proper properties filtering based on an allow-list. Either guessing objects properties or providing additional object properties in request payloads, allows attackers to modify object properties they are not supposed to and which are assumed immutable by the server, allowing attackers to modify properties they are not supposed to on the data objects stored in the backend.

How AppCheck can help

AppCheck contains checks for specific data deserialization vulnerabilities, however it does not currently attempt to brute-force additional object properties so may not detect all vulnerabilities in this area.

API7:2019 Security Misconfiguration

Security misconfiguration is another broad category of vulnerabilities, commonly a result of insecure default configurations, incomplete, out of data 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.

How AppCheck can help

AppCheck will detect and report on a broad range of security misconfigurations within APIs. Some checks, such as outdated or weak TLS configurations, are shared in common with the scanning of user-facing web interfaces, whereas others are specific to the scanning of APIs and parsing of the responses.

API8:2019 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.

How AppCheck can help

AppCheck performs a number of checks for a large variety of injection attacks within APIs, to build up a rationale as to why it thinks an application in vulnerable, where it is vulnerable and provides an example of the payload it used to confirm the vulnerability. This includes tests for SQL injection, NoSQL / Server Side JavaScript injection, Command Injection, Code Injection, Template Injection, Edge Side Includes Injection, XPath Injection, LDAP Injection, HTTP Header Injection, URL Rewrite Injection, Cross Site Scripting, and XML External Entity Injection.

API9:2019 Improper Assets Management

APIs tend to expose more endpoints than traditional web applications, and new methods can be added by developers over time, or expanded to different consumers, without considering whether it is safe to do so. Additionally, attackers may discover non-production versions of the API (for example, staging, testing, beta, or old/legacy versions that have not been retired) that are not as well protected as the production API, or have debugging enabled, providing attackers with information that can be used to launch their attacks against the production instance.

How AppCheck can help

AppCheck will perform checks including brute-force path discovery to attempt to discover legacy or alternative API versions that may remain published and available. However a focus on documenting and inventorying APIs is important additionally for organisations in relation to their API "footprint".

By default, configured infrastructure target scans will include an additional, lightweight passive web application scan of any web services encountered, which can be used to help identify web API's that may have been overlooked.

API10:2019 Insufficient Logging & Monitoring

Lack of proper logging, monitoring, and alerting allows attacks and attackers go unnoticed. 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.

How AppCheck can help

It is critical that logging and monitoring is performed as a cohesive function, incorporating both technical (logs, Security Information and Event Management (SIEM) system integration) as well as human (alerting, monitoring, response) functions.

This category is extremely challenging to test for via vulnerability scanning. Since logs are not typically exposed externally, it is not possible for a scanner to confirm if security events are audited (recorded) correctly – and certainly not whether logs are then subject to triggering alerts and being manually reviewed by security staff. To fully review this area would involve interviews with security operations staff or asking if attacks were detected during a scan.

Through creating a realistic attack scenario, AppCheck helps to flex monitoring and logging solutions and so can highlight weaknesses and omissions in current processes, but this must be performed in hand with manual review by customer security or incident response teams - for which our security team are always on hand to offer advice on best practice.