OWASP API Security Top 10 2019

By / / Application Security, Cybersecurity Articles, Vulnerabilities & Exploits / API, API Security, Application, AppSec, authentication, Authorization, DOS, jTop 10, OWASP, SDLC, SQLi

The Open Web Application Security Project (OWASP) has released its OWASP API Security Top 10 2019. This is the first version of the API Top 10. OWASP will likely update the guidelines every three to fours years, similar to the other OWASP Top 10 series.

OWASP says the primary goal of the OWASP API Security Top 10 is to educate technology professionals, such as developers, designers, architects, and managers, to “create awareness about modern API security issues.”

The Application Programming Interface (API) is a critical, foundational part of Internet of Things (IoT) solutions, modern mobile apps, Software-as-a-Service (SaaS) and web applications, just to name a few.

APIs are a set of definitions and protocols developers use to allow their products or service to communicate to other products or services.

Although APIs are critical for rapid innovation and integration, APIs can also expose application logic and sensitive personal data. Thus, APIs are a prime targets for attackers.

We have provided some highlights from the OWASP API Top 10 risks (also see PDF report), along with some of OWASP’s suggested mitigations that you can use to help address API vulnerabilities.

API1 – Broken Object Level Authorization

According to OWASP, object level authorization checks should be considered in every function that accesses a data source. The authorization checks should validate the logged in user has access to perform the requested action on the requested object.

Without these authorization protections, an attacker could manipulate the API endpoint, such as Object ID sent within the request, and gain access to sensitive data.

In addition to authorization checks, OWASP also recommends developers use “random and unpredictable” values as GUIDs used for record IDs. Organizations should also deploy Write tests to evaluate the authorization mechanism.

API2 – Broken User Authentication

Attackers can compromise authentication tokens or exploit poorly implemented authentication mechanisms. As a result, the system’s ability to improperly identify the client/user can compromise the overall API security.

In one scenario, attackers can use “credential stuffing” or list of known breached passwords in common attacks to gain unauthorized access.

Some OWASP best practices to prevent broken user authentication can include, but not limited to:

  • Use the OWASP Authentication Cheatsheet.
  • Implement Multi-factor authentication where feasible.
  • Deploy anti-brute force mechanisms on your endpoints to mitigate credential stuffing, dictionary attacks and brute force attacks.
  • Implement account lockout and captcha solutions to prevent brute force against specific users.
  • Check for and prevent weak passwords.
  • Make sure authentication is used for users and API keys for projects (such as application or site).

API3 – Excessive Data Exposure

In excessive data exposure, attackers can sniff traffic and then analyze the API responses. As a result, they can look for exposed data that should not be returned to the user.

To help prevent excessive data exposure vulnerabilities, developers should not rely on client side to filter sensitive data. In addition, engineers should also review API responses to make sure they contain only legitimate data.

OWASP furthermore recommends software engineers classify sensitive personal data stored in applications and review API calls that return such data for any responses that pose a security issue. Engineers should also implement a schema-based response validation to help define and enforce data returned by API methods (to include errors).

API4 – Lack of Resources & Rate Limiting

API resources that don’t limit the number or size of connections requested by a client/user are susceptible to denial of service (DoS) attacks. API requests can also consume network and system resources (e.g., CPU, memory and storage), making systems and services unresponsive.

According to OWASP, developers can implement the following security safeguards for layers of protection against resource and rate limiting risks:

  • Implement limits on how often a client can call the API within a certain time period.
  • Add server-side validation for query string and request body parameters (to include controls around number of records returned in the response).
  • Enforce limits on the maximum size of incoming parameters and payloads.

API5 – Broken Function Level
Authorization

Attackers could take advantage of the complexity of access control policies and URL paths without proper authorization controls for user/administrative role separation. These issues could allow attackers regular user access to administrative endpoints or perform privileged activities.

OWASP provides the following mitigations to help protect against broken functional level authorization vulnerabilities:

  • Deny all access by default and explicitly grant access to authorized roles for every function.
  • Review API endpoints for functional level authorization vulnerabilities.
  • Implement authorization checks based on the user’s group/role (via administrative controllers that need to inherit from an administrative abstract controller).

API6 – Mass Assignment

In mass assignment, attackers can bind client provided data/parameters into internal object properties they should not have access to. This issue can also occur without proper whitelist filtering of properties.

To add, bad actors can guess (and then modify) object properties by exploring API endpoints or inserting properties into request payloads.

According to OWASP, developers and engineers should implement the following security controls to guard against mass assignment risks:

  • Do not use functions that automatically bind a client’s input into code variables or internal objects.
  • Whitelist only properties that should be updated by the client.
  • Blacklist properties via built-in features that should never be accessed by clients.
  • Explicitly define and enforce schemas for the input data payloads.

API7- Security Misconfiguration

Security misconfigurations can include unsecure default configurations, incomplete configurations, wide open cloud storage (such as S3 buckets) and misconfigured HTTP headers. In addition, developers may mistakenly add unnecessary HTTP methods or allow error messages to contain sensitive information.

To help prevent security misconfigurations, developers and engineers can deploy:

  • Hardening process to ensure deployment is locked down to documented set of secure configurations.
  • Process to review and update secure configurations across the API stack.
  • Automated process to continuously monitor and assess configuration hardening settings.
  • Mechanism to prevent exception traces and other sensitive information from being sent back to attackers.
  • Proper Cross-Origin Resource Sharing (CORS) policy.

In addition, OWASP also recommends to make sure APIs can only be accessed by the specified HTTP verbs. Furthermore, developers should make sure all other unnecessary features and HTTP verbs (e.g., HEAD) are disabled.

API8 – Injection

Injection flaws can include SQL injection, noSQL injection or command injection vulnerabilities. These issues occur when untrusted data is sent to an interpreter via a command or query. As a consequence, an attacker could use bad data to trick the interpreter into executing malicious commands or accessing data without authorization.

OWASP recommends the following controls to separate data input from commands and queries:

  • Perform data validation using a single, trustworthy, and actively maintained library.
  • Validate, filter, and sanitize all client-provided data (or other data coming from integrated systems).
  • Make sure any special characters are escaped using the specific syntax for the target interpreter.
  • Use a safe API that provides a parameterized interface.
  • Always limit the number of returned records to prevent mass disclosure in case of injection.
  • Validate incoming data by using sufficient filters to only allow valid values for each input parameter.
  • Define data types and strict patterns for all string parameters.

API9 – Improper Assets Management

Developers and engineers may lack properly updated inventory and documentation of all API endpoints, hosts and API versions. Outdated documentation or inventory may make it harder for organizations to keep assets patched and API versions updated. As a consequence, unpatched API hosts could result in vulnerability exploits and sensitive data leaks.

To help prevent improper assets management, OWASP recommends the following safeguards:

  • Inventory all API hosts and document important aspects of each asset such as environment (e.g., production, development), who should have access (e..g, public, internal) and API version.
  • Inventory and document integrated services, as well as data flows and its sensitivity.
  • Document API authentication, errors, redirects, rate limiting, cross-origin resource sharing (CORS) policy and endpoints, including their parameters, requests, and responses.
  • Generate documentation automatically by adopting open standards. Include the documentation build in your CI/CD pipeline.
  • Make API documentation available to those authorized to use the API.
  • Use external protection measures such as API security firewalls for all exposed versions of your APIs.
  • Avoid using production data in non-production APIs (if required, make sure same security protections are used).
  • Perform risk analysis on newer versions of APIs.

API10 – Insufficient Logging & Monitoring

In the final OWASP Top 10 risk category, systems and API endpoints may have insufficient logging and monitoring. As a result, these issues can make incident response procedures ineffective when a bad actor attacks the organization’s systems.

“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,” OWASP stated.

OWASP recommends organizations deploy the following logging and monitoring controls:

  • Log events with sufficient detail (e.g., failed authentication attempts, denied access and input validation errors) to identify had actors.
  • Make sure logs cannot be tampered with at rest and in transit (i.e., log integrity).
  • Make sure all logs originating from API stack/hosts are aggregated and managed in a Security Information and Event Management (SIEM) system.
  • Ensure log format can be consumed by SIEM.
  • Continuously monitor infrastructure to make sure APIs are functioning.
  • Configure custom dashboards for alerts and suspicious activities (for rapid detection/response).

In conclusion, the OWASP API Security Top 10 provides excellent guidance for developers, software engineers and organizations to prevent API-related vulnerabilities and reduce risk.

Readers can also check out the OWASP Top 10 – 2017 list for the ten most critical web application security risks.