API Pentesting | TryHackMe

An API (Application Programming Interface) is a structured interface that enables software components to communicate with each other. When a user logs into a mobile banking app, scrolls through a social media feed, or places an order on a delivery platform, the client device makes API calls to a back-end server to fetch data, submit information, and trigger actions. Rather than loading full web pages with HTML and styling, APIs typically exchange lightweight data in JSON format. This efficiency and flexibility is why APIs have become the backbone of modern application architecture.

In API-driven architectures, the back-end exposes a set of endpoints that any client can call independently. A single API may serve a web application, a mobile application, and third-party integrations simultaneously. This means the API itself becomes a critical attack surface. If the API is vulnerable, every client that depends on it is affected.

API security testing shares some overlap with traditional web application testing, but introduces a distinct set of challenges. APIs do not have a visible user interface that restricts what a user can do. There are no buttons to click or forms to fill out. An attacker interacts directly with the raw endpoints, meaning they can craft and send any request without being limited by what a front-end application chooses to expose. This directness opens up vulnerability classes that are less common in traditional web testing, such as Broken Object Level Authorization and mass assignment.

In a typical API security engagement, you receive a collection of in-scope endpoints (often as an Insomnia or Postman collection) and test each one for vulnerabilities. You examine how the API handles authentication, whether it enforces proper authorisation on every resource, and whether it exposes more data than necessary in its responses. The goal is to find flaws that an attacker could exploit to access unauthorised data, escalate privileges, or disrupt the service.

Learning Objectives

By the end of this room, you will be able to:

Understand the fundamentals of RESTful APIs, including how requests and responses are structured and how authentication is typically handled
Read and interpret API requests and responses in JSON format
Identify and exploit common API vulnerabilities outlined in the OWASP API Security Top 10, such as BOLA, Broken Authentication, and Mass Assignment
Understand how modifying request parameters, headers, and body fields can expose security flaws
Recognise defensive strategies that protect APIs against the vulnerabilities explored in the room

Prerequisites

Before starting this room, you should be comfortable with the basics of HTTP, including request methods, headers, and status codes. The following rooms provide the necessary background:

Answer the questions below

I am ready to learn about API pentesting!

Decode the JWT returned by the login endpoint. What role is assigned to the testuser account?

customer

Access user 1's profile through the BOLA vulnerability. What is their email address?

admin@shop.thm

Retrieve user 1's order history. What is the flag contained in one of their orders?

THM{b0la_1s_the_numb3r_0ne_ap1_r1sk}

Were you able to modify another user's data using a PATCH request? (yea/nay)

yea

What HTTP status code indicates that rate limiting is in effect?

429

What password did you discover for the admin account?

sunshine

In the raw API response for sarah.chen, what sensitive field contains a bcrypt hash?

password_hash

What information is revealed in the internal_notes field of sarah.chen's profile?

Flagged for suspicious activity on 2025–01–15

What is the term for the developer practice of applying all client-supplied fields directly to a data model without filtering?

mass assignment

After adding "role": "admin" to the PATCH request, what is your new role?

admin

Using your escalated privileges, access the admin users endpoint. How many total users are registered on the platform?

What is the flag returned by the admin endpoint?

THM{m4ss_4ss1gnm3nt_pr1v_3sc}

What field in the profile response did you use to identify the escalation path?

role

What value did you set that field to?

admin

What is the flag?

THM{ch41ned_ap1_vulns_f0r_the_w1n}

CONCLUSION

This room covered the fundamentals of API security testing, progressing from RESTful API architecture through to chaining multiple vulnerabilities in a simulated attack scenario.

Recap

Task 2 established the foundation: HTTP methods and their CRUD mappings, status codes relevant to security testing, JSON request and response structure, and the three common authentication mechanisms (API keys, Bearer tokens, and JWTs).

Task 3 introduced BOLA, the number one OWASP API Security Top 10 risk. You accessed other users' profiles and orders by changing object IDs in requests, and confirmed that the vulnerability extended to write operations.

Task 4 demonstrated brute-forcing an unprotected login endpoint and examined how APIs that return entire database objects in their responses leak sensitive data to anyone who inspects the raw JSON.

Task 5 escalated privileges through mass assignment by injecting a role field into a profile update request, and covered rate limiting abuse beyond authentication endpoints.

Task 6 required you to chain these techniques without guidance, progressing from profile inspection to privilege escalation to flag retrieval.

Defensive Measures

Object-level authorisation: Every endpoint that references a specific resource must verify that the authenticated user is permitted to access it. This check cannot be handled by a global middleware alone, because the relationship between a user and a resource differs for every endpoint.

Response filtering: Return only the fields appropriate for the requesting user's role. Do not serialise entire database objects. Many frameworks provide serialisation libraries or response schema definitions for this purpose.

Input allowlisting: Define an explicit list of writable fields for every endpoint that accepts a request body. Silently ignore anything not on the list. Fields like role, is_admin, and permissions should never be writable through client-facing endpoints.

Rate limiting: Apply globally, with stricter limits on sensitive endpoints. Include standard rate limiting headers (X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset) in responses.

JWT security: Use strong signing secrets, reject the none algorithm, validate exp claims, and keep token lifetimes short.

Further Resources

The OWASP API Security Top 10 (opens in new tab)(2023 edition)
PortSwigger's Web Security Academy(opens in new tab) includes free API testing labs.

For practice against intentionally vulnerable APIs, crAPI (Completely Ridiculous API) is an OWASP project that can be run locally with Docker.

Useful tools for real-world API testing include Burp Suite for intercepting API traffic, Insomnia and Postman for crafting and organising API requests, ffuf for endpoint brute-forcing, jwt_tool for JWT testing, and OWASP ZAP as an open-source alternative.