So, what is an API?

An API is bridge or path that allows to system software to communicate with each other. It lets one program request data or services from another program without knowing that how it works internally.

For just an Example:

Think that API is like a waiter in the restaurant

  1. You (Client) → Place an order
  2. Waiter (API) → takes your request to the kitchen
  3. Kitchen (Server) →Prepares the food
  4. Waiter (API) → brings the food back to you

Real Life Example:

When you use mobile app to check the weather, the app does not store the data itself. instead:

  1. The app sends the request to weather API.
  2. The API asks the weather server.
  3. The server sends the weather data.
  4. The API return the results to your app.

So basically, APIs interact the user(client) to the server or server to the user(client). So, APIs help different system share data and services easily.

Common API Method:

API usually use HTTP methods:

  1. GET → retrieve data
  2. POST → sends or create data
  3. PUT → Update data
  4. Delete → remove data

GET /users/25 = this means get the information of user 25.

What is API Testing?

API testing is the process of checking whether an API works correctly, securely, and efficiently.

Instead of testing the user interface (like buttons or web pages), API testing checks the communication between software systems

API Testing Checks:

  1. If API returns the correct data.
  2. If it handles request easily.
  3. If it protects sensitive information.
  4. If it works securely without vulnerability.

Why API Testing is Important

APIs are used in almost every modern application such as:

  • Mobile apps
  • Websites
  • Payment systems
  • Cloud services

If an API is not secure, attackers may:

  • access private data
  • modify information
  • bypass authentication
  • perform unauthorized actions

That is why API security testing is very important in cybersecurity and web penetration testing.

What is Checked During API Testing

During API testing, testers usually check:

1. Functionality Testing

Check whether the API works correctly.

Example: If you request user data, does it return the correct information?

2. Security Testing

Check if the API has security weaknesses.

Example:

  • Can someone access data without login?
  • Can attackers manipulate requests?

3. Performance Testing

Check how the API behaves under heavy traffic.

Example:

  • Does it slow down?
  • Does it crash?

4. Error Handling

Check how the API reacts to wrong requests.

Example: If you send invalid input, does the API return a proper error message?

API testing is important as vulnerabilities in APIs may undermine core aspects of a website's confidentiality, integrity, and availability.

API RECON (API Reconnaissance)

When starting API testing, the first thing is API recon (API reconnaissance). This means collecting as much information as possible about the API to understand how it works and where it can be tested.

The first thing is to find the API endpoints. An endpoint is specific URL where the API receives request for a certain resource on the server.

For Example:

GET /api/books HTTP 1.1

host: example.com

So here, api/books is the API end point. This endpoint is use to request a list of books from the server. Another end point could be api/books/mystery, which would return a list of mystery books

After identifying the end points, the next step is how to interact with them. this helps you to create valid HTTP requests to properly test the API.

While analyzing the API, you should try to discover:

  • Input data — what information the API accepts, including required and optional parameters.
  • Request types — which HTTP methods the API supports, such as GET, POST, PUT, or DELETE.
  • Media formats — the data formats the API uses, such as JSON or XML.
  • Rate limits — how many requests can be sent in a certain period.
  • Authentication mechanisms — how the API verifies users, such as API keys, tokens, or login sessions.

API documentation

APIs are usually documented so that developers know how to use and integrate with them.

Documentation can be in both human-readable and machine-readable forms. Human-readable documentation is designed for developers to understand how to use the API. It may include detailed explanations, examples, and usage scenarios. Machine-readable documentation is designed to be processed by software for automating tasks like API integration and validation. It's written in structured formats like JSON or XML.

API documentation is often publicly available, particularly if the API is intended for use by external developers. If this is the case, always start your recon by reviewing the documentation.

Using Machine-Readable API Documentation (Important topic):

Sometimes API documentation is available in in machine readable format, such as JASON or YAML. This means documentations is written in the structured format that tools and software's can easily understand.

Security testers or pentesters can use these tools to analyze the API documentations and quickly learn how the API works.

For example, Burp Scanner can be used to crawl and audit OpenAPI documentation or other documentation files written in JSON or YAML. This helps testers automatically discover API endpoints and check them for possible vulnerabilities.

Another useful tool is the OpenAPI Parser extension in Burp Suite. It can read OpenAPI documentation and extract important information such as endpoints, parameters, and request methods. This makes it easier to understand how the API should be tested.

Testers can also use special tools like Postman or SoapUI to sends request to the documented API endpoints and test whether they work correctly or not or they have security issues.

In Simple words machine-readable documentation allows security, testers to analyze the API's and test them more them efffieciently by using the tools.

What is an OpenAPI Parser?

An open API Parser is tool that reads and understand an OpenAPI specification file and converts it into a format that can be easily understand by developers and security tester.

At first, we should have to understand that how an OpenAPI works. It usually contains information such as:

  1. API endpoints and the URLs
  2. Request the methods (GET, POST, LOGIN, DELETE)
  3. Parameters
  4. Data Format
  5. Authentication Requirement

These details is usually written in files like:

  1. openapi.jason
  2. swagger.jason
  3. openapi.yaml

An OpenAPI Parser reads the files and extract all the information about the API structure. This makes it easier for tools, developers, and pentesters to understand how the API work.

For Example:

Suppose there is a file called: openapi.jason

It contains Information about API endpoints such as:

  1. /api/users
  2. /api/products
  3. /api/orders

The OpenAPI Parser will read this file and lists all the end points, parameters, anfd request types so that they can be easily tested.

Why OpenAPI Parser is useful?

An OpenAPI Parser helps to:

  1. Understand the structure of API.
  2. Identify the available endpoints.
  3. Discover the required parameters.
  4. Automatically generate API request.
  5. Assist's in API testing and security analysis.

ACCORDING TO MY CONCLUSION

An OpenAPI Parser is a tool that reads API documentation files (like openapi.json or swagger.json) and extracts important information such as endpoints, parameters, and request methods so that developers and testers can easily understand and test the API.

Identifying API Endpoints (Simple Explanation)

When testing an API, you can learn a lot by browsing the application that uses the API. Even if API documentation is available, it is still useful to explore the application because sometimes the documentation may be old, incomplete, or incorrect.

You can use Burp Suite to help with this process. For example, Burp Scanner can crawl the application and automatically discover different pages and requests. After the crawl, you can manually explore interesting parts of the application using Burp's browser to find possible vulnerabilities.

While browsing the application, pay attention to URL patterns that may indicate API endpoints, such as:

/api/
/api/users
/api/products

These URLs often show that the application is communicating with an API.

You should also check JavaScript files used by the website. These files sometimes contain hidden references to API endpoints that are not directly visible when browsing the site normally.

Burp Scanner can automatically extract some endpoints during the crawl, but for deeper analysis you can use the JS Link Finder BApp extension. This tool scans JavaScript files and helps find additional API endpoints.

You can also manually review JavaScript files in Burp Suite to discover endpoints and understand how the API is being used by the application.

In simple terms, exploring the application, analyzing URLs, and reviewing JavaScript files can help testers discover hidden API endpoints and understand the API structure better.

Using Intruder to Find Hidden API Endpoints (Simple Explanation)

After you find some initial API points, you can use burp suite's burp intruder to find some hidden API endpoints that are not immediately visible.

For example:

PUT /api/user/update

The end point is used to update user information

You find any other API hidden endpoints you can use burp intruder to to replace the word update with other possible actions. For instance, you can try other common functions name likes:

  1. /api/user/delete
  2. /api/user/add
  3. /api/user/create
  4. /api/user/update

By sending these requests you find that whether these is available on the server or not.

When searching for hidden endpoints, it is helpful to use worldlists that contain common API names and actions. These lists include words that the developers commonly use when creating the APIs.

We can also use the word that are related to the application or web that we are testing, based on the information we discovered during our initial API reconnaissance.

In easy words, Burp intruder helps the testers guess and discover the hidden API endpoints by trying many possible endpoints.

Finding Hidden API Parameters (Simple Explanation)

During an API recon, we may discover that an API suports some parameters and that are not mentioned in the documentation. These are called hidden parameters or undocumented. Sometimes using this hidden parameters csn change how the application behaves or reveal additional functionality.

Burp suites provide many tools to find these hidden parameters

  1. Burp Intruder:

It allows the testers to test automatically many possible parameters names by using a wordlist of common parameters name. Intruder can replace the existing parameters and or add newone to the request. It is also useful to include parameter names related to the specific application based on your initial API's recon.

2. Parm Miner:

The other heplful tool is Parm miner. This tool can automatically guess a large number of possible parameter names upto (upto 65,356) in a single request. Parm miner also suggests the parameters name that are relevant to the application by using information from the testing scope.

3. Content Discovery:

There is also a tool name content discovery. This tool helps to discover hidden content that is not directly linked in the visible parts of the application. It can also help find hidden directories, endpoints, and parameters.

Mass Assignment Vulnerabilities

Mass assignment vulnerability happens when a web application automatically takes all the parameters from a user request and connects them into fields inside the application internal object.

Many web framework's do this automatically to make development easily this process is called auto binding.

The problem occurs when the application accepts more parameters than the developer intended. Some of these parameters may control sensitive fields that should not be changed by the user.

For example, suppose a user profile contains these fields:

username email password isAdmin

When a user updates the profile, the developer might only be expecting the:

username email

But if the application automatically binds all parameters, an attacker could send a request:

username=Ali email=Ali@gmail.com isAdmin=True

Mass assignment vulnerabilities happen when an application accepts and processes hidden parameters that developers never meant to allow users to control.

How to Detect Mass Assignment Vulnerabilities (Pentester Perspective)

When testing an API, a pentester should check if the application accepts hidden parameters that were not intended by the developer. These hidden parameters may allow attackers to change sensitive values.

The first step is to look at the API request and response carefully. When you send a request, check if the response contains fields that you did not send. These fields may indicate hidden parameters used by the application.

For example, suppose you send this request: POST /api/user/update

with the data: username=Ali email=ali@email.com

But in the response you see something like: { "username": "Ali", "email": "ali@email.com", "role": "user", "isAdmin": false }

Here you discovered two additional fields: role isAdmin These may be sensitive parameters.

The next step is to try modifying these parameters manually. Using tools like Burp Suite or Burp Repeater, you can send a modified request such as: username=Ali email=ali@email.com isAdmin=true If the server accepts this change and updates the value, then the application may have a mass assignment vulnerability.

Tools That Help Find Mass Assignment

Security testers often use tools like:

  • Burp Suite
  • Burp Intruder
  • Param Miner

These tools help test many parameters automatically and identify hidden fields.

Simple Pentester Strategy

When testing for mass assignment, remember these steps:

  1. Identify API endpoints.
  2. Send normal requests and analyze responses.
  3. Look for hidden fields in responses.
  4. Try adding or modifying those fields in the request.
  5. Check if the application accepts the change.

THE MAIN OF THIS ALL IS:

A Mass Assignment vulnerability occurs when an API allows users to modify hidden or sensitive parameters that should not be controlled by the user.

Preventing vulnerabilities in APIs

When developers design the API, they should know about the security from the very beginning and so they can protect the website from the attackers and also from any sort of vulnerability. This helps the API to protect from the attackers and reduces the chances of any sort of vulnerability.

  1. If the API is not meant to be public, the API documentation should also be protected so that unauthorized peolple can access it. At the same time, the documentation should also be kept updated, so that the developers and security testers (Pentesters) can easily understand how the API works and wha endpoint exists.
  2. Developers should also only allow specific HTTP methods that are needed for the API. For example if an endpoint only needs to retrive the data, it should only allow the GET request and block others like POST or DELETE.
  3. Another important step is to check the content type of requests and responses. The API should make sure that the data format (such as JSON) is what the server expects.
  4. API also use generic error messages. Detailed error messages can reveal the useful information to the attackers about how the system works.

To prevent mass assignment vulnerabilities, developers should clearly define which properties or fields a user is allowed to update. These allowed fields should be placed in an allowlist, while sensitive fields such as admin roles or permissions should be blocked so that users cannot modify them.