OWASP API Top 10

What is API security?

An Application Programming Interface (API) can be defined as the middle man to a program’s backbone. Modern software is designed as stacks, more like sandwiches and APIs rest in the middle acting as a communicating relay between the program and the hardware drivers. Or else, from a web developer’s point of view, between one service and another. APIs are widely used in modern cloud services and it’s one the common ways how microservices and containers communicate.

Businesses use APIs to connect their services and transfer data. Take twitter for an example, twitter plugins which display chucks of a twitter feed in other websites use the twitter API to access that feature. With the use of API, twitter and other major companies can share their information and let third parties access their services without sharing their code.

https://developer.twitter.com/en/docs/twitter-for-websites/follow-button/overview

Often times APIs work with sensitive data such as application logic and Personally Identifiable Information (PII). Thus, it is prone to become the target of attackers who seek to benefit from accessing and obtaining those data.

83% of the web traffic generated today are from API calls. Compared to user interfaces (UI), exposed APIs will form a larger attack surface and it’s estimated to become the number 1 attack target by 2022.

Since APIs have already become a foundational element of the web technologies that are thriving today, the need for securing APIs has never been a more paramount concern than now.

What is the OWASP API Top 10?

Open Web Application Security Project (OWASP) has released a number of (ten, to be precise) substantial vulnerabilities that exist within APIs. We’ll be taking a look at each of them in detail in the following sections and the prevention methods for each of them.

https://www.slideshare.net/QAFest/qa-fest-2019-api

1. Broken Object Level Authentication

This is also known as the Insecure Direct Object Reference (IDOR). Traditionally your rest APIs based on paths to resources, rely on the client to maintain the state and figuring out what it needs. These APIs tend to expose the endpoints of object identifiers.

Imagine a situation where you are logged into your bank account and you request to view your financial information, if the back-end doesn’t properly check for authentication or authorization then an attacker can use a different account to mimic the API call to access your account information, using the exposed object identifier by modifying the user input.

https://apisecurity.io/encyclopedia/content/owasp/api5-broken-function-level-authorization.htm

Object-level authorization checks must be in place for every function that accesses the data source using input from the user.

https://medium.com/@sagarag/api-security-how-to-avoid-broken-object-level-authorization-broken-function-level-authorization-f93b9b5ac333

Imagine another situation of a web application — that allows students to view their marks and the Teachers to add marks for their respective subjects. If the Oauth scopes aren’t defined properly, providing read/write access to the teacher and read-only access to the student, the web application is vulnerable to being exploited by one of its users, which might try to manipulate the sensitive data that’s stored in the system.

How to prevent it?

• perform authorization checks at API gateways, or in a remote policy evaluation point.
• For locally running APIs, use traditional Role-Based Access Controls (RBAC) (i.e Java, Springboot)

2. Broken Authentication

When software developers incorrectly implemented authentication controls it causes a case of broken authentication.

• User authentication credentials are not protected when stored
• Users using predictable login credentials
• The session IDs are exposed in the URLs
• The session ID is vulnerable to session fixation attacks? tricking a user to authenticate using a session ID we chose.
• Session valued do not time-out or get invalidated after logout
• Session ID’s are not rotated after successful logins
• Passwords, session IDs and other sensitive credentials are sent over unsecured, unencrypted connections

are some of the common situations of broken authentication.

broken authentication and session management

How to prevent it?

• User credentials must be protected using hashing or encryption when stored
• Don’t expose the session ID in the URL
• Sessions should expire after a time
• Renew session ID with every login
• Do not send credentials over unsecured, unencrypted connections. Use secure transfer protocols as TLS with perfect forward secrecy (PFS) ciphers and secure parameters.
• Demand users to use complex passwords
• Enforce account disabling after a number of failed attempts to log in
• Multi-factor Authentication

3. Excessive Data Exposure

When APIs retrieve full data objects from the backend database and relies on clients to filter the data out, an attacker can use this to their advantage and make it reveal information that a UI would normally filter out.

How to prevent it?

• Never rely on clients to filter out data!
• Define schemas for API responses carefully
• Define all the sensitive data and justify its use, clarify what’s sensitive according to privacy laws, regulatory requirements or business needs
• Enforce response checks to prevent accidental leaks
• Discard sensitive data after it served its purpose or use PCI DSS compliant tokenization or even truncation.
• Encrypt all sensitive data, use strong algorithms

4. Lack of Resources & Rate Limiting

APIs generally don’t put limitations on the no of requests that can be requested from a client or a server. This might result in attackers sending requested more than the API could handle, basically overloading it. It can affect the API’s processing speed essentially clogging it up.

https://stripe.com/blog/rate-limiters

How to prevent it?

• Limit the payload size
• Define proper rate limiting
• Add checks on compression ratios
• Define limits for container resources

Imagine a limited API being spoken via a backend process, and you want to limit the API for 20 requests per second, then you can have 1 process to allow those 20 requests to pass through.

Below is an example of how a rate limiter works in Node.js.

https://apisyouwonthate.com/blog/what-is-api-rate-limiting-all-about

5. Broken Function Level Authorization

Overly complicated hierarchies, groups and roles and unclear separation between administrative and regular functions lead to authorization flaws. When such administrative functions are exposed, non-privileged users can access these functions if they know how to.

Example:

/api/users/v1/user/myinfo
/api/admins/v1/users/all

How to Prevent it?

• Do not rely on the client to enforce admin access
• Deny all access by default (Implicit Deny)
• Group operations by roles
• Test authorization to and use proper design principles

6. Mass Assignment

The best way to explain this vulnerability is to demonstrate it in an example.

The concept of a Mass Assignment is that often times, a web form will implement a model binding, by taking the information sent in the POST request and binding it with the relevant model in the database.

The API takes the data the client provides and stores it without proper filtering or sanitization for whitelisted properties. Thus, blindly transforms the user-provided payload into an object of the API and stores it.

node.js takes the information provided in the request body and modifies the object

How to prevent it?

• Do not automatically bind user-provided data with internal objects
• Explicitly define all parameters and payloads you are expecting
• Use readOnly property on an object that doesn’t need to be modified
• Precisely define the patterns and schemas you will accept in requests

7. Security Misconfiguration

Poor configuration of security in servers causes attackers to exploit them. Also leaving security configs as defaults can cause the same. Imagine a scenario when a server’s directory listing is not disabled by default. An attacker can simply list directories to find any file and execute it and even get a hold of the source code of the application and find more vulnerabilities.

Another scenario is when unnecessary administration ports being open for an application, which exposes the application to remote attacks.

Also, un-updated legacy applications might contain vulnerabilities.

https://www.tutorialspoint.com/security_testing/testing_security_misconfiguration.htm

How to prevent it?

• Establish a repeatable hardening and patching process
• Automate locating configuration flaws
• Disable unnecessary features/ ports.
• Restrict administrative access
• Define and enforce all outputs, including errors. (Make sure you don’t display the errors to clients)
• Least privilege access

8. Injection

Injection flaws occur when developers create dynamic database queries that include user-supplied input and attackers use that construct API calls that SQL, NoSQL, LDAP, OS or other commands that the API or the backend behind it blindly executes. Therefore, to prevent such attacks from happening, developers must either:

1. Stop writing dynamic queries
2. Prevent user-supplied input which contains malicious SQL from affecting the logic of the executed query

How to prevent it?

Setup your primary defenses:

1. Use of prepared statements with parameterized queries
2. Use of stored procedures
3. Whitelist Input Validation
4. Escaping All user-supplied input

Additional Defenses:

1. Enforcing the least privilege
2. Performing whitelist input validation as a secondary defense

// Vulnerable to injection attacks — no pramertarization
export const one = async (id: number) => {
return new Promise((resolve, reject)) => {
Connection.query(‘SELECT * from blogs WHERE id = ${id}’, (err,results)) => {
if(err){
return reject(err)
}
resolve(results);
});
});
}
// After implementing params
export const one = async (id: number) => {
return new Promise((resolve, reject)) => {
Connection.query(‘SELECT * from blogs WHERE id = ?’, [id] (err,results)) => {
if(err){
return reject(err)
}
resolve(results);
});
});
}

9. Improper asset management

APIs prefer to reveal more endpoints than traditional web apps, giving high priority to adequate and modified information. Adequate hosts and installed versions of API implementations still play an important role in minimizing problems such as obsolete variants of APIs and open debug endpoints.

Attackers may find API that may still be in its early stages (beta, testing, staging, etc) and take advantage of the fact that it not being well protected as a post-production API, and use it to deploy their attacks.

Many of the DevOps, cloud, Kubernetes environments used in development are vulnerable to this since they use API that is mostly in testing stages.

Desire to make their software backward compatible leaves it being vulnerable to being exploited since it still relies on older outdated software.

Not maintaining proper versions and not updating their APIs puts the Application in danger as well.

How to prevent it?

• Keep an up to date inventory of all APIS
• Limit access to anything that should not be public
• Limit access to production data, and segregate access to production and non-production data.
• Implement additional external controls, such as API firewalls.
• Properly retire old versions of APIs or backport security fixes to them.
• Implement strict authentication, redirects, CORS, and so forth

Insufficient logging and monitoring

Lack of proper logging of the processes that happen within the API, (the user logins, etc) and consistent monitoring of those logs to detect anomalies is the number 10 and the final vulnerability of OWASP top 10 for APIs.

Emphasis on the point monitoring since, regardless of how well you perform the logging of the daily tasks of your API/ Web Application, it is equally, if not more important to monitor them to find anomalies, if they may be one.

One of the most overlooked aspects of logging is not securing the log files. An attacker shouldn’t be able to access that file and modify it. Its integrity must be protected.

logging failed login attempts

How to prevent it?

1. Log failed attempts, denied access, input validation failures, or any failures in security policy checks.
2. Ensure that logs are formatted so that other tools can consume them as well.
3. Protect logs like highly sensitive information.
4. Include enough detail to identify attackers.
5. Avoid having sensitive data in logs — if you need the information for debugging purposes, redact it partially.
6. Integrate with SIEMs and other dashboards, monitoring, and alerting tools.

Resources —

OWASP API Security Project — https://www.owasp.org/index.php/OWASP_API_Security_Project

API Security Articles — https://apisecurity.io/

What is API security? Redhat — https://www.redhat.com/en/topics/security/api-security