What is API?

An API stands for Application Programming Interface. It is a software intermediary that allows two applications to communicate with each other using a set of definitions and protocols. An API architecture usually contains a client and server. The application sending a request is called client, and the application sending a response is called server.

What is API Security?

In the present application-driven world, the programming interface plays a crucial role in the development process. API security is built in such a way that attackers won’t be able to breach the system. API security is a critical part of current web application security. Some commonly found vulnerabilities are broken authorization, authentication and code injection etc. API security is important because businesses use APIs to connect services and transfer data.If an API gets hacked, it can lead to a data breach.

Top 10 OWASP API Security 2019

1. API1:2019 Broken Object Level Authorization

APIs tend to expose endpoints that handle object identifiers, creating a wide array of surface-level access control issues. So each API ought to have object-level authentication security that accesses the information using the input from the client.

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 the 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 lead to unauthorized information disclosure, modification, or destruction of all data.

2. API2:2019 Broken User Authentication

Incorrect implementation of authentication mechanisms are often which allows the hackers to compromise with authentication tokens or to exploit implementation flows to assume others users identity temporarily or permanently. This will lead to compromise in systems ability to identify client/ user.

Authentication endpoints and flows are assets that need to be protected. “Forgot password / reset password” should be treated the same way as authentication mechanisms.

An API is vulnerable if it:

Permits credential stuffing whereby the attacker has a list of valid usernames and passwords.

Permits attackers to perform a brute force attack on the same user account, without presenting captcha/account lockout mechanism.

Permits weak passwords.

Sends sensitive authentication details, such as auth tokens and passwords in the URL.

Doesn’t validate the authenticity of tokens.

Accepts unsigned/weakly signed JWT tokens (“alg”:”none”)/doesn’t validate their expiration date.

Uses plain text, non-encrypted, or weakly hashed passwords.

Uses weak encryption keys.

3. API3:2019 Excessive Data Exposure

Most developers search for nonexclusive executions and probably expose all object properties vulnerabilities, relying on the client to filter the data before displaying it to the user.

The API returns sensitive data to the client by design. This data is usually filtered on the client side before being presented to the user. An attacker can easily sniff the traffic and see the sensitive data.

4. API4:2019 Lack of Resources & Rate Limiting

APIs do not always limit the number or frequency of requests from a single API client. So API clients can make thousands or even more API requests per second. It can result in low server performance, causing Denial of Service (DoS) attacks.

API requests consume resources such as network, CPU, memory, and storage. The amount of resources required to satisfy a request greatly depends on the user’s input and endpoint business logic. Also, consider the fact that requests from multiple API clients compete for resources. An API is vulnerable if at least one of the following limits is missing or set inappropriately (e.g., too low or high):

• Execution timeouts
• Max allocable memory
• Number of file descriptors
• Number of processes
• Request payload size (e.g., uploads)
• Number of requests per client/resource
• Number of records per page to return in a single request response

5. API5:2019 Broken Function Level Authorization

Sometimes API tends to have an unclear separation between admin level and regular functions that leads to authentication flaws. Exploiting these issues, attackers gain access to users’ data and administrative functions.

The best way to find broken function level authorization issues is to perform deep analysis of the authorization mechanism, while keeping in mind the user hierarchy, different roles or groups in the application, and asking the following questions:

• Can a regular user access administrative endpoints?
• Can a user perform sensitive actions (e.g., creation, modification, or erasure) that they should not have access to by simply changing the HTTP method (e.g., from GET to DELETE)?
• Can a user from group X access a function that should be exposed only to users from group Y, by simply guessing the endpoint URL and parameters (e.g., /api/v1/users/export_all)?

Don’t assume that an API endpoint is regular or administrative only based on the URL path.

While developers might choose to expose most of the administrative endpoints under a specific relative path, like api/admins, it’s very common to find these administrative endpoints under other relative paths together with regular endpoints, like api/users.

6. API6:2019 Mass Assignment

The API stores the information provided by the client without any legitimate separation for whitelisted properties. Attackers can try to guess object properties or add properties to their request, which they are not supposed to do with data present in the backend.

Objects in modern applications might contain many properties. Some of these properties should be updated directly by the client (e.g., user.first_name or user.address) and some of them should not (e.g., user.is_vip flag).

An API endpoint is vulnerable if it automatically converts client parameters into internal object properties without considering the sensitivity and exposure level of these properties. This could allow an attacker to update object properties that they should not have access to.

Examples for sensitive properties:

• Permission-related properties: user.is_admin, user.is_vip should only be set by admins.
• Process-dependent properties: user.cash should only be set internally after payment verification.
• Internal properties: article.created_time should only be set internally by the application.

7. API7:2019 Security Misconfiguration

Poor configuration in API servers like misconfigured HTTP headers, open cloud storage etc allows attackers to exploit them. 

The API might be vulnerable if:

• Appropriate security hardening is missing across any part of the application stack, or if it has improperly configured permissions on cloud services.
• The latest security patches are missing, or the systems are out of date.
• Unnecessary features are enabled (e.g., HTTP verbs).
• Transport Layer Security (TLS) is missing.
• Security directives are not sent to clients (e.g., Security Headers).
• A Cross-Origin Resource Sharing (CORS) policy is missing or improperly set.
• Error messages include stack traces, or other sensitive information is exposed.

8. API8:2019 Injection

Attackers make API calls that contain SQL, NoSQL or other command injections that can expose the data without proper authorization.

The API is vulnerable to injection flaws if:

• Client-supplied data is not validated, filtered, or sanitized by the API.
• Client-supplied data is directly used or concatenated to SQL/NoSQL/LDAP queries, OS commands, XML parsers, and Object Relational Mapping (ORM)/Object Document Mapper (ODM).
• Data coming from external systems (e.g., integrated systems) is not validated, filtered, or sanitized by the API.

9. API9:2019 Improper Assets Management

Attackers find non- production versions of API(e.g. Staging, testing, beta or older ) that are not well protected as the production API and use those to initiate the attack.

The API might be vulnerable if:

• The purpose of an API host is unclear, and there are no explicit answers to the following questions:
  • Which environment is the API running in (e.g., production, staging, test, development)?
  • Who should have network access to the API (e.g., public, internal, partners)?
  • Which API version is running?
  • What data is gathered and processed by the API (e.g., PII)?
  • What’s the data flow?
• There is no documentation, or the existing documentation is not updated.
• There is no retirement plan for each API version.
• Hosts inventory is missing or outdated.
• Integrated services inventory, either first- or third-party, is missing or outdated.
• Old or previous API versions are running unpatched.

10. API10:2019 Insufficient Logging & Monitoring

Improper logging in and monitoring can encourage attackers to breach systems and destroy the data.

The API is vulnerable if:

• It does not produce any logs, the logging level is not set correctly, or log messages do not include enough detail.
• Log integrity is not guaranteed (e.g., Log Injection).
• Logs are not continuously monitored.
• API infrastructure is not continuously monitored.