# A Fresh Look At OWASP API Security Top 10


With continuous growth and expansion in technology. Software development teams are applying modern practices in building software. This has led to applications built on the cloud using a microservices architecture.

While this architecture is a great tool to build applications, they have a small-sized nature and are not coupled much. Developers use application programming interfaces (APIs) to integrate the applications.

APIs are efficient in connecting software components and have many benefits. But, these APIs have become targets of malicious attacks on applications.

In this article, we are going to look at OWASP, and OWASP API Top 10 List and explain each one of them with examples of abuse on each of them.

## What Is OWASP
The word **OWASP** is an acronym which means Open Web Application Security Project.
OWASP is a worldwide community responsible for web application protection.
This organization is a non-profit that provides free resources on how to improve software security.

## What Is OWASP API Security Top 10
The OWASP API Security Top 10 is a document that the OWASP community updates with up-to-date attacks on APIs and workable solutions.

Developers build most modern applications with microservices architecture.

The microservices are loosely coupled so they integrate them with APIs. These APIs developers use to run these applications are in charge of data.

Attackers would attack these APIs because of their vulnerability and have access to the full system.

That was how OWASP API Security Top 10 came to be. The document highlights the top ten vulnerabilities that could breach the security of a program.

## OWASP API Security Risks
This list was last updated on 2019, the top ten OWASP API security risks include:

### 1. Broken Object Level Authorization

APIs use object-level authorization to authorize legitimate users.

When we leave the API endpoint exposed and unsecured, an attacker can gain access to it by changing the Ids.

For example, when a consumer makes a request containing a `userid` to an API, like;

https://docs.com/document?userID=12

If the object level authorization is broken or not implemented. An attacker could gain unauthorized access by changing the userId to something like:

https://docs.com/document?userID=13

If the new `userid` above guessed by the attacker is in the program.

The attacker will gain unauthorized access to the consumers’ data without undergoing authorization. Or the attacker will guess another number that will be in use in the program.

### 2. Broken User Authentication

There are so many authentication processes done in an application like resetting passwords, login authentication and so on.

We do these normally using APIs. If developers fail to design these API endpoints differently from other API endpoints. Or they fail to implement the authentication correctly.

Then, malicious agents can access the accounts of legitimate users in the application.

Some examples where broken user authentication can occur include:

* Weak passwords

* Weak Encryption Keys

* Non-encrypted or unhashed passwords

* Unvalidated or insecure JWT tokens

* Failure to limit the number of tries for a digit in authentication

When the user authentication is broken in any of these cases, attackers can have access to a user’s account.

For example, an attacker might try to reset a password by sending a POST request to

https://myapp.com/api/auth/password_reset

The API would send some digits to the legitimate user for verification.

The attackers can use an automated system to guess those digits and continue trying until they get the right guess.

This happens so fast that it can take minutes to get the right guess. Here, the developers did not implement the API to limit the number of tries.

Hence, there could be guesses of up to thousands or millions before they get the right digit.

### 3. Excessive Data Exposure

APIs return data to the frontend but some of this data returned could contain sensitive information.

We expect developers to filter out sensitive data and send it to the frontend.

Malicious users can call an API directly even if the developers had filtered it and they would still have direct access to the API.

For example, if we made an application of user API endpoint to show the details of a user.

https://myapp.com/api/users/{userId}

A malicious user can sniff through the user details and get access to too much information like;

GET userId

[ 
    {
         "Name": syxxx, 
         "Id": 0,
         "Address": "xxxx, xxxxland", 
         "Phone Number": [phone],
     }
 ]

This data contains too much information like the users home address and phone digits.

### 4. Lack Of Resources $ Rate Limiting

When some APIs cannot limit the number of requests, they can get from a particular client.

An attacker can take advantage of this and make too many queries from the API.

This will make the API exceed its performance and run down making it unresponsive to other users.

For example, if we could set a certain API endpoint for users' info to a limit of only 20 entries per page.

https://myapp.com/api/users_info?page=1&entries=20

Hackers can increase the entries if there is no limit on the API endpoint like:

https://myapp.com/api/users_info?page=1&entries=2000

This will overwhelm the API server and cause it to be unresponsive to other users.

Hackers can also use the absence of rate limiting to reset a user’s password and have access to their info.

### 5. Broken Function Level Authorization

This happens when users have access to specific functions on the site or even admin functions.

When we do not configure an API properly, it could give room for users to have unwanted access to other features.

For example, A blog application has a feature that will allow its users to export their blog info.

GET

https://myapp.com/api/posts/export_info

If there is a flaw in the API endpoint, then the user can export all the users blog info like this:

GET

https://myapp.com/api/posts/export_info/all

In another scenario,
An unauthorized user could register as an admin on a site and have access to all the users' information.

### 6. Mass Assignment

Many frameworks of today have features like object-relational mapping. Where developers can bind input from users to variables.

Some examples of such frameworks are Ruby on Rails, Java Play Framework, ASP.NET MVC and so on.

These features help to speed up development time but after they deploy the code to production.
Hackers can take advantage of these features to manipulate users' data.

For example, in an e-commerce application, an authorized user might have access to details like user.addDiscount and use it.

Another example, Hackers could make themselves the admin of a site by adding the code:

PUT

[ 
    {
         "is_admin": true,
         "is_sso: true, 
         "role":"admin",
         "Sso_type":"admin",
     }
 ]

In this example, the hacker has manipulated the data by giving himself admin rights. So he can access the application and tamper with sensitive data.

### 7. Security Misconfiguration

When there is a misconfiguration in an application infrastructure or an API. This can give attackers access to the application.

When there is loose protection on an API, an attacker can take advantage and launch an attack.

Some of these misconfigurations in an application are:

* Unnecessary http methods

* Use of default usernames and passwords

* Use of default ports

* Cross-origin site sharing

* Directory traversal

* Open cloud storage

For example, an attacker might search through computers on a popular search engine directly connected to the internet. If they find a host using a default port with a default configuration and no authentication. They can easily access the host and have access to all the records in it.

### 8. Injection

This is when APIs receive data from consumers of that API but the data contains commands/queries that are not trusted.

For instance, SQL injection is a good example of an attack.

In an SQL injection, they make a query to an API endpoint which could damage or alter the application.

Example:

In an application, we use an API to get `userID`.

GET

api/info/users?=12

The request above will return the user with the specified ID.

But an attacker can inject SQL into the code

GET

api/info/users?=12; DROP USER

Here, the program will retrieve `user id ` first and delete it afterwards.

In a command injection, an attacker could make a command to an API endpoint that will tamper with the records.

### 9. Improper Asset Management

With rapid delivery cycles, most DevOps teams constantly push their code to production with their APIs.

Sometimes the software deployed may be in the testing phase like beta and when in beta, the developers may fail to protect the APIs.

Malicious agents could use those insecure APIs to have unauthorized access.

For example,

A game application pushed new APIs into production but left the old APIs for backward compatibility. Without updating the security features on the old APIs.

A hacker found the new API

api.games.com/v2

And changed it to;

api.games.com/v1

This gave the hacker access to all the records in the application.

### 10. Insufficient Logging $ Monitoring

When APIs cannot log login attempts or password resets or any other activity going on in it.

A malicious agent might take advantage of it and cause severe damage to the application.

Developers should design APIs to watch and log activities. So it would be easier to detect malicious attacks and prevent them from further happening.

For example,

In a service application, an attacker tries to log in and gain access to an application and there are no logs of the activity.
The attacker continues to attempt undetected until they gain full access and tamper with the customer records.

[In a real life experience,](https://healthitsecurity.com/news/insurer-dominion-national-reports-server-hack-that-began-august-2010) a health application that health workers use to store health records was hacked and the attacker had access to all the records on the site.
The attacker had access to the site for nine years undetected. If application logged activities then this would have been detected.

## Summary

Now we have seen what vulnerabilities APIs face and how they can affect the entire system.

This calls for more vigilance and cares in securing API endpoints.

For more information on OWASP API, you can check the [OWASP official site for more information.](https://owasp.org/www-project-api-security/)