Hello Friend,

I recently read Hacking APIs and got really interested in the OWASP API Top 10. Reading was good, but I wanted to actually try things out myself.

That’s when I picked up DVAPI, a vulnerable API lab built by Payatu. It’s like a playground full of common API mistakes that you can exploit and learn from. While working on it, I also got more familiar with Postman and API testing in general.

In this writeup, I’m sharing how I went through the challenges — what I tried, what worked, what failed, and what I learned. I’ll explain the vulnerabilities in simple words, show my steps with screenshots, and also talk about how these issues could be fixed if they happened in a real system.

I hope you enjoy reading this as much as I enjoyed solving it.

Setting up DVAPI

To get started with the DVAPI lab, follow the steps below:

  1. Clone the repository:
git clone https://github.com/payatu/DVAPI.git
  1. Navigate to the DVAPI directory:.
cd DVAPI
  1. Use docker compose to build and run the application:
docker compose up --build
  1. Access the DVAPI application at http://127.0.0.1:3000

1. Broken Object Level Authorization

Description

Drop off during a CTF challenge? No problem. Store a secret note on your profile to track your progress and resume where you left off.

http://192.168.64.5:3000/api/getNote?username=inv1nc

About the Vulnerability

Broken Object Level Authorization (BOLA) occurs when an API exposes object IDs or parameters directly without enforcing proper authorization. Attackers can modify those IDs (usernames, account IDs, note IDs) to access data that isn’t theirs.

Solution

I tested the getNote endpoint with my username, then swapped it with admin’s username. The server didn’t validate ownership and just gave me admin’s note. That directly revealed the flag.

Flag# flag{bola_15_ev3rywh3r3}

Why this Happened

The API trusted the username parameter instead of checking against the authenticated session.

Remediation

  • Always enforce authorization checks on the server side.
  • Never trust client-supplied identifiers for sensitive resources.
  • Use session-based ownership validation.

2. Broken Authentication

Description

Admin has a challenge for you. Admin says anyone who can log in with their account will get some surprise. Can you find out the surprise?

About the Vulnerability

Broken Authentication in APIs often comes from weak tokens, poorly managed secrets, or flawed session handling. JWTs signed with weak keys are especially dangerous because they can be brute-forced.

Solution

I decoded my JWT and saw it was signed with HS256 (HMAC-SHA256). I dumped the token into John with rockyou.txt and cracked the signing secret—it was just secret123.

Using jwt.io, I forged a new token where I changed username to admin and isAdmin to true, signed it with the cracked key, and sent it to /api/profile. The server accepted it and gave me the flag.

Flag# flag{aBus1ng_w34K_s3cR3TTT}

Why this Happened

  • The JWT secret was weak and easily brute-forced.
  • The server trusted isAdmin claims directly from the token instead of validating from a backend source.

Remediation

  • Use strong, random secrets (not dictionary words).
  • Consider RS256 (asymmetric JWT signing).
  • Never trust client claims directly; always verify roles against your database.

3. Broken Object Property Level Authorization

Description

Ever wished there was a cheat code to top the scoreboard?

About the Vulnerability

This is a Mass Assignment issue. APIs that automatically bind user input to backend models without filtering can let attackers modify hidden or sensitive fields (like isAdmin, balance, score).

Solution

I tried injecting a score field in random endpoints like password change and note creation—no luck. Then I tested the /api/register endpoint.

I sent:

{
  "username": "omniman",
  "password": "viltrum",
  "score": 100000
}

It worked. My new account appeared on the scoreboard with a score of 10,000 (capped by the app). When I fetched /api/scores, I saw my boosted rank and the flag.

Flag# flag{br0k3n_oBj3cT_Pr0p3rTy_L3v3L_Auth0RiS4Ti0N}

Why this Happened

The backend automatically mapped all incoming JSON properties to the database user object, without restricting which fields clients could set.

Remediation

  • Implement input whitelisting — only allow expected fields.
  • Use DTOs (Data Transfer Objects) instead of directly binding JSON to models.
  • Review all models for sensitive attributes.

4. Unrestricted Resource Consumption

Description

Do you know that you can customize your profile? Try it out and make your profile stand out among others.

About the Vulnerability

This is an example of Unrestricted Resource Consumption. If an API doesn’t restrict file sizes, attackers can upload very large files, causing performance issues or denial of service.

Solution

I generated a 100MB dummy file with:

dd if=/dev/zero of=100mb.jpg bs=1M count=0 seek=100

Then uploaded it as my profile picture. The server accepted it without validation, and I immediately got the flag.

Why this Happened

The server didn’t enforce limits on file size or validate uploads properly.

Flag# flag{file_size_is_important}

Remediation

  • Enforce strict file upload size limits.
  • Validate MIME types and file contents.
  • Implement server-side checks for disk usage.

5. Broken Function Level Authorization

Description

DVAPI has many users. You can see other’s profile and others can see yours. What could go wrong here? Right? Right???

About the Vulnerability

Broken Function Level Authorization occurs when sensitive functions (like delete, update, or admin actions) are exposed without proper access control.

Solution

I checked /api/user/omniman with an OPTIONS request and saw it allowed GET, HEAD, DELETE. Out of curiosity, I tried:

DELETE /api/user/omniman

Even with a normal user token, it worked—I deleted another account and got the flag.

Why this Happened

The server failed to enforce function-level authorization, exposing admin-only functionality to regular users.

Flag# flag{n0_fUncTi0N_L3v3L_aUtH???}

Remediation

  • Implement role-based access control (RBAC).
  • Never expose admin-only endpoints to regular users.
  • Validate permissions server-side for every action.

6. Unrestricted Access to Sensitive Business Flows

Description

DVAPI is a people first applicaiton. We are keen on knowing your requests through submit ticket function. Maybe it’ll help you find the flag !!!

About the Vulnerability

Unrestricted access to sensitive business flows happens when critical operations lack controls such as rate limiting, abuse detection, or proper authorization.

Solution

I sent repeated POST requests to /api/addTicket with:

{ "message": "I need help" }

Each request created a new ticket. There was no rate limiting or spam prevention. After spamming multiple requests, the flag appeared.

Why this Happened

  • No rate limiting or business logic controls.
  • Tickets could be spammed endlessly without validation.

Flag# flag{n0_r4t3_L1m1T?}

Remediation

  • Add rate limiting, throttling, or CAPTCHA for sensitive actions.
  • Monitor abnormal traffic patterns.
  • Validate ticket creation rules (e.g., one per user per interval).

7. Server-Side Request Forgery (SSRF)

Description

DVAPI is using a function to set SecretNote for your user through a link/url. Try to learn more about SSRF and capture the flag !!!

About the Vulnerability

SSRF happens when an API fetches URLs provided by the user without validation. Attackers can trick the server into making requests to internal services (localhost, cloud metadata endpoints, etc.).

Solution

I tested by setting a note with http://google.com. The server fetched Google’s page and stored it.

Then I tried hitting http://localhost:3000 , The server responded with 200, proving it could connect to its own internal services.

Then I tested a non-open port http://localhost:525, This returned a 500 error, indicating the port was closed.

To go further, I attempted brute-forcing all 65,535 ports. Unfortunately, I wasn’t able to discover another valid open port in my lab environment — likely because of a deployment issue with the dockerized setup.

Why this Happened

The API blindly trusted and fetched user-supplied URLs without validation.

Flag

Not solved in my setup (deployment issue).

Remediation

  • Restrict outbound requests to a safe allowlist.
  • Block access to internal IP ranges.
  • Sanitize and validate user-supplied URLs.

8. Security Misconfiguration

Description

The Developers at DVAPI are lazy which has led to a misconfigured system. Find the misconfiguration and submit the flag !!!

About the Vulnerability

Security Misconfiguration occurs when default settings, debug errors, or unhandled exceptions expose sensitive details to attackers.

Solution

I sent a malformed JWT token. Instead of gracefully failing, the server returned a detailed stack trace in the response. The flag was directly visible in the error.

Why this Happened

The server didn’t handle JWT parsing errors securely and exposed debug info.

Flag# flag{St4cK_tR4c3_eRR0R}

Remediation

  • Disable stack traces in production.
  • Return generic error messages.
  • Log technical details internally, not to users.

9. Improper Inventory Management

Description

There was a data leak at DVAPI. People found out there are 12 Challenges and not 10, What do you think ?

About the Vulnerability

Improper Inventory Management happens when APIs expose undocumented or hidden endpoints that can be enumerated or misused.

Solution

I looked at /api/allChallenges?released=1, which listed active challenges.

Out of curiosity, I changed released to other values. After several attempts, I tried released=unreleased, and it showed hidden challenges—along with the flag.

Why this Happened

  • Hidden/unreleased endpoints were left exposed.
  • Lack of proper versioning and endpoint management.

Flag# flag{a553Ts_m4N4g3m3NT_g0n3_wR0ng}

Remediation

  • Maintain a proper API inventory.
  • Disable or remove unreleased/test endpoints from production.
  • Use API gateways to manage versioning and visibility.

10. Unsafe Consumption of APIs (NoSQL Injection)

Description

API’s used at the Authentication of the application does not look safe, can you test it and get the flag ??

About the Vulnerability

If APIs consume untrusted data directly into NoSQL queries (MongoDB, etc.), attackers can inject operators like $ne, $gt, etc., to bypass authentication.

Solution

At the login endpoint, I tried a NoSQL injection payload:

{
  "username": "admin",
  "password": { "$ne": 1 }
}

MongoDB interpreted $ne:1 as “password not equal to 1”, which was always true. That bypassed login checks and authenticated me as admin, revealing the flag.

Flag# flag{eZ_n0SQLi_pWn}

Why this Happened

  • The API directly inserted user input into a MongoDB query without sanitization.

Remediation

  • Use parameterized queries or safe ORM libraries.
  • Sanitize input before passing it to database queries.
  • Enforce strict schema validation for request payloads.

Thanks for reading!!