Common API Vulnerabilities

Understanding Common Vulnerabilities will help you when you identify weaknesses when you’re testing APIs

We’ll cover most of the vulnerabilities included in the OWASP API Security Top 10 and other useful weakness : information disclosure and business logic flaws, and techniques to exploit

  • Table of Content

Information Disclosure

APIs are used to facilitate communication and data exchange between different software systems, and they play a crucial role in modern application development and Sometimes developer mistakenly disclose sensitive information here.

Information disclosure can be disclosed in various ways, depending on the specific vulnerability or weakness in the system. Here are some common areas where information disclosure can occur →

  1. Error messages: Inadequate error handling can result in detailed error messages being returned to users or attackers. These messages may contain sensitive information such as database names, table names, or internal system paths.

  2. API responses: APIs may unintentionally include sensitive data in their responses. This can happen if the API does not properly filter or redact sensitive information before sending the response.

  3. Log files: Improper logging practices can lead to sensitive information being stored in log files. If log files are not properly secured or monitored, they may become a target for attackers looking to extract valuable information.

  4. Configuration files: If configuration files are not adequately protected, they may contain sensitive information such as database credentials, API keys, or encryption keys.

  5. Source code comments: Developers sometimes leave comments in the source code that unintentionally reveal sensitive information. These comments may be overlooked during code reviews and can be accessible to anyone with access to the source code.

  6. Directory listings: If directory listings are enabled on web servers, attackers may be able to browse directories and access sensitive files or directories that should not be publicly accessible.

  7. HTTP headers: Improperly configured HTTP headers can reveal sensitive information about the server or application, such as server versions or internal IP addresses.

  8. Metadata and file properties: Documents, images, or other files may contain metadata or properties that reveal sensitive information, such as author names, locations, or revision history.

  9. Backup files and archives: Sometimes, backup files or archived versions of websites or applications are not properly secured and may contain sensitive information that was not intended to be exposed.

Basically Sensitive data can include any information that helps attacker to gain advantage.

Ex → a site using wordpress API unknowingly sharing information with anyone who navigates to API Path /wp-json/wp/v2/users, Which returns all the WordPress usernames, or ‘slugs’.

GET https://www.sitename.org/wp-json/wp/v2/users

It Might Return like ;


[{”id”:2,”name”:”Krishna”, “slugs”:””}]

These slugs can used to attempt to login as the disclosed users with brute-force, credential-stuffing, or password-stuffing, or password-spraying attack ( will discuss in further series )

Error Messages

or Verbose messages helps API consumers to implement their application in right way. However, it can also reveal sensitive information about resources, users, and the API’s architecture like version of web server or databases)

Ex → you attempt to authenticate to an API and receive an error message such as “the provided user ID doesn’t exist.” then, you changed the User ID and error changes to “Incorrect Password”.

It let you know that User ID that you entered is correct so if there is no rate limit then you can try to brute forcing the Password of that user or try to bypass the rate limit and then try to brute force

You can gather the most information by interacting with an API endpoint and analyzing the response. API Responses can reveal information within headers, parameters, and verbose errors.

Other Good Source of information disclosure are API Documentation and resources gathered during reconnaissance

Broken Object Level Authentication

Occurs when API provider allows an API consumer access to resources they are not authorized to access.

Why it Happened ? → if an API endpoint doesn’t have object-level access controls, it won’t perform checks to make sure users can only access their own resources.

Object Level Authentication ? → APIs use some sort of values, such as names or numbers, to identify various objects

What we should do as hunter here ? → When we discovered these object IDs, We should test to see if we can interact with the resources of other users when unauthenticated or authenticated as different user


"name":"Radhe Krishna"


This poses no problem since we are authenticated to access Radhe Krishna’s Data. However,

if we are able to access another user’s information, there is BOLA vulnerability

What to do ?

In this situation, we might check for these problems by using another identifications number which is close to Radhe Krishna’s ID which is 852.

Congrats 🎉 : You Found BOLA

Note : For the application to be vulnerable, it must fail to verify that a given user is only able to access their own resources

How do we know that ? → this is object and this is not ?

By detecting patterns within API paths and parameters, you should be able to predict other potential resources.

following colored elements should catch your attention :

GET /api/resources/1
GET /user/accounts/find/user_id=4
POST /company/account/peter/balance
POST /admin/pwreset/account/52

You can replace these colorized objects by examining the right pattern. “peter” is the username you can try to access other user’s username by simply replacing the peter

You just have to Examine right pattern of objects to FIND BOLA

Broken User Authentication

It refers to any weaknesses within the API Authentication process.

When it Occurs ? →

When API provider either doesn’t implement any Auth. Protection or Implemented wrong way

Why it Happen ? →

As, you Know REST APIs are supposed to be stateless. To maintain this statelessness API often require user to go threw registration process in order to obtain unique token.

User can include the token with each request to demonstrate that they are authorized to make requests.

What NExt ?

  • To test on token generation process if it is weak, collect samples of token if generated token doesn’t rely on high level of randomness, or entropy then there is high chance that you can generate your own token by properly examining the token

  • Token Handling method of transmitting tokens across network, the presence of hard coded token and so on.

if fails to Token Handling leads to detect hard coded tokens in Javascript source files or capture them by analyze web application

After Capturing Token ? → once authenticated using token

  • We can access to previous forbidden files, previously hidden endpoints or to bypass detections

Other Authentication : registration system

One another authentication mechanism which is registration process

  • password reset and multi-factor authentication features

EX:→ Imagine a password feature requires email address and six-digit code for verification

  • you can simple guess the six-digit code by brute forcing 1 million times

Until no rate-limit set

We can perform numerous attacks against API Authentication , such as auth bypass, brute forcing attacks, credential stuffing, and a variety of attack against tokens.

Excessive Data Exposure

Excessive data exposure when an API endpoint responds with more information than is needed to fulfil a request.

How it occurs → occurs when the provider expect the API consumers to filter the requests

→ Requesting information for their user account and receives information about other users accounts as well : API Exposing Excessive DATA

You Sent → GET /api/v3/accounts?name=krishna

Got following JSON in response

                    "email":"[email protected]"

Requested For user ******krishna but provider responded with information about the person who created this account

How to Detect ? →

  • test target API endpoints

  • review the information sent in response

Lack of Resources and Rate Limiting

API Providers monitize their API by limiting requests and allowing paid customer to requests more information

Why Rate limiting ? →

  • Rate limit plays very important role in the API monetisation by service provider.

  • too many requests without rate-limiting will lead to provider's system crashing and become unavailable → denial of service (DOS) state

Attacker Perspective ? →

Can Bypass rate limits can cause additional costs for the API Provider

What after if Rate Limit is Applied ?

Once you are restricted from making additional requests

Try bypass it by:

  • adding or removing parameters

  • play with request headers

  • using different client

  • altering your IP address

Broken Function Level Authorization

When it Occurs ? →

User of one role or group is able to access the API functionality of another role or group

Different Different Role ? →

Local user, Public user, merchant user, partner user, admin user and so on.

BFLA is present if you are able to user the functions of a more privileged group

Different Btw BFLA & BOLA ? →

BOLA except instead of an authorisation problem involving accessing resources. BFLA is authorisation problem for performing actions.

EX→ a vulnerable Banking Website API.

  • if BOLA present : you might be able to access the information of other accounts, such as payment histories, usernames, email addresses and account numbers.

  • IF BFLA present : You might be able to transfer money and actually update the account information

BOLA is about authorisation access whereas BFLA is about authorisation actions.

Different Privilege functionality :

Application Could have → different endpoints to perform different priviledge actions

  • it may use /{user}/accounts/balance endpoint for accessing their account balance

  • it may use /admin/account/{user} endpoints for an administrator wishing to access any user account informations

If Access control doesn't implemented correctly → user will able to perform administrative actions, like seeing user's full account details by simple making administrative request.

It doesn't need to be always use endpoints for administrative functionality :

  • Functionality could based on HTTP Methods such as GET, POST, PUT, DELETE

Provider need to restrict on What HTTP Methods a consumer can use

💡 If Provider doesn't restrict the HTTP Methods for consumers then attacker's can simply make unauthorised request using different HTTP methods leads to BFLA Vulnerability

When hunting For BFLA

look for functionality you could use to your advantage, including altering user accounts, accessing user resources, and gaining access to restricted endpoints.

📓 Note :

  • Easiest way to discover BFLA is to find API Documentation and send requests as an unprivileged user to test admin functions and capabilities

  • As an unprivileged user, make request included in the admin sections, such as attempting to create users, update user accounts, and so on. Successful request will discovered BFLA otherwise 401 or 403

  • If API Documentation isn't available → you need to discover or reverse engineer the endpoints used to perform privilege actions. Found Administrative endpoints ?, Then you can begin making requests

Mass Assignments

When it Occurs ? →

occurs when an API consumer includes more parameter in their requests than application intended and the application adds these parameters to code variable or internal objects.

  • consumer may be able to edit object properties or escalate privilege

Ex : →

API is called to create an account with parameters for “User” : “Password”


Suppose you discovered parameter “isAdmin”:true from API Documentation, Intercepting API Requests and responses or by fuzzing in API Request

If API doesn’t sanitize the request input, it is vulnerable to Mass Assignment too

Where to Find Paramenters ?

→ As I said you could find from API Documentation, Intercepting API Requests and responses or by fuzzing in API Request

Security Misconfiguration

→ Mistakes done by developers said Security Misconfig.

  • lead to sensitive information being exposed or a complete takeover

  • Lack of Input Sanitization: all command injection, XSS, Malicious Uploads and etc

  • Misconfigured headers result in information disclosure, downgrade attacks, Xss

API header uses additional services to enhance their API services and it’s common for those additional services to add headers

X-Powered-By: Vulncure
  • X-Powered-By: reveals backend technology. helps to know the exact backend supporting services

  • X-XSS-Protection: use to prevent XSS attack.

  • X-Response-TIme: Provides the response time

X-response-Time →consistent response time for non-existent record but it could be used to check if event is triggered or some process happened in backend and it is obvious in incrementation of response time

HTTP /User1 404 Not Found

HTTP /User2 404 Not Found

HTTP /User3 404 Not Found


💡 callUser3 might exist because of his unexpected response time

With this small sample of users’ response time, it is hard to conclude that User3 exists but if you have 100rs or 1000nds of requests

Un-necessary HTTP Methods

if API provider allows unnecessary HTTP Methods, there is an high risk in info. disclosure, might lead to delete data.

  • always try defaul credentials


injection flaws occurs when input isn’t filtered and allows unwanted characters, as result in injection flaws

Backend → basically application might treat data from the request as code and runs it and you’ll be able to conducts injection attacks such as SQLi, NoSQLi, command injections.

Any clue ? → Verbose error messages, HTTP response code and unexpected API behavior

POST /api/v1/register HTTP 1.1
Host: example.com

"Fname": "Narender",
"Lname": "Hacker",
"Address":"' OR 1=0-- -"  -> SQLi payload 

Any error directly from database indicates clearly that there is an injection vulnerability

EX → Error: You have an error in your SQL syntax….

💡 Note :

Injection vulnerability often complemented by other vulnerabilities such as poor input sanitization.

and might results in command injection

EX → To Take advantage of this make a get req. but manipulating the parameter


By manipulating the Field show=/etc/passwd results in command injection attack

nuucp:*:6:5:uucp login user:/var/spool/uucppublic:/usr/sbin/uucp/uucico
jdoe:*:202:1:John Doe:/home/jdoe:/usr/bin/ksh

How to Find ? →

Finding injection flaws involves thorough testing of API endpoints, careful monitoring of the API's responses, and crafting requests that aimed at manipulating the backend systems.

Improper Assets Managements

occurs when organisation exposes their APIs that either retired or still in development

Causes ? → lead to other vulnerability such as excessive data exposure, information disclosure, information disclosure, mass assignment, improper rate limiting and API injection

Discovering this should be your first step toward further exploitaion of an API

How to discover Improper assets managements ? →

paying close attention to outdated API documentation, changelogs, and version history on repositories

Organizations often include version info. in endpoints like /api/v3/users/token and etc

you might try to change the version from v3 to v1 or v2 and test those if not trashed/exist

How to discover it ? →

You can discover IAM by guessing, fuzzing or brute-forcing requests. Watch for pattern in APi doc or path-naming scheme and then make request on your assumptions

Business Logic Vulnerabilities (BLV)

intended features of Application that could me maliciously used.

Ex→ API uploaded feature that doesn’t validated encoded payloads, used could upload any file as long as it encoded, allows end user to upload and execute arbitrary code, include malicious payloads

  1. One of the leading causes of This vulnerability is Experian trusted the partner not to expose the API cause in leakage of API keys, tokens and passwords

You can Seach API Doc for telltalke signs

  1. like Only use feature X to perform function Y

  2. Do not do X with endpoint Y

  3. Only admins should perform req X

This indicates that API provider is trusting you won’t do any of the discouraged actions

  1. Developer assume consumer will exclusively use a browser and won’t capture API req. lead to info. disclosure, API key leakage or use parameter the could be use negatively

POST /api/v1/login HTTP 1.1
Host: example.com

by manipulating MFA=true to MFA=false could lead to bypass multifactor authentication

Conclusion :

Testing Bysiness logics could challenging because each business are unique, Automated scanner might not be able to detect any

You need to understand how business and API operates and then consider how you could use these features to your advantage by try breaking assumptions of developers

Last updated