Lab Overview

This free lab is a playground for exploring and exploiting OWASP API Security Top 10 vulnerabilities using the vulnerable crAPI (Completely Ridiculous API) application.

Quick Start Guide

Click the Run button to launch the crAPI virtual machine. Click Connect VPN and follow the instructions (if applicable).

This lab runs for 1 hour by default. You can click Extend to increase the time.

It may takes up to 5 minutes for machine to fully start

Tool -> Burp Suite (Pre-installed on Kali Linux):
A powerful tool for web application security testing. You’ll use it to intercept requests, view data sent between your browser and the server, and manually modify requests. Think of it as a live editor for everything your browser does under the hood.

Access the Application

crAPI Web Interface

URL: http://192.168.10.76:8888

Login Credentials:

Email: [email protected]
Password: P@ssw0rd!

What You’ll Practice

Your mission is to explore multiple hands-on challenges designed to simulate real-world API vulnerabilities found in modern web applications. The scenarios were executed against crAPI (Completely Ridiculous API), a deliberately vulnerable platform developed to train and assess API security testing skills.

crAPI includes real-world flaws found in modern APIs. Practice exploiting these:

• (API1) Broken Object Level Authorization (BOLA)

• (API2) Broken User Authentication

• (API3) Excessive Data Exposure

• (API4) Lack of Rate Limiting

• (API5) Mass Assignment

• (API6) SSRF

• (API7) Broken Function Level Auth (BFLA)

• (API8) Insecure JWT Handling

• (API9) Security Misconfigurations

• (API10) NoSQL Injection

Tools Required

• Burp Suite (pre-installed in Kali Linux)

• VPN access (Optional for direct access via private IP Address)

Tips

Always have Burp Suite open and proxying your browser. Use HTTP History to review past requests even if you miss them. Look at both requests and responses—vulnerabilities are often hidden in responses. Don’t just follow steps—ask: “Why does this work?”

Troubleshooting crAPI

If the application becomes unresponsive:

Access machine via Desktop or ssh, and run the following commands:

# Navigate to the crAPI directory
cd /home/owasp

# Restart crAPI using Docker Compose
sudo docker-compose -f docker-compose.yml down    # (optional) stop all services
sudo docker-compose -f docker-compose.yml up -d   # start in detached mode

# Confirm containers are running
sudo docker ps

Broken Object Level Authorization (BOLA) It happens when an application uses user-supplied identifiers (like user_id, vehicle_id, etc.) to access objects but fails to verify ownership of those objects.

Example: a user with id = 100 tries to access an information/object/properties of another user with id = 102 by channing the parameter user_id in http request from 100 to 102.

Goal: Access another user's vehicle location by changing the vehicle ID in an intercepted request.

Tools Used

burpsuite – A web proxy tool used to intercept and manipulate HTTP requests/responses between your browser and the application.

• You'll use Proxy to intercept the requests.

• You'll use Repeater to modify and resend them.

Important Note: Run the burpsuite before start the challenge ((Applications > 01-Reconaissance > burpsuite))

Step 1: Login and Understand the App Flow

Start by exploring the application like a normal user:

http://192.168.10.76:8888

Login using:

Email: [email protected]
Password: P@ssw0rd!

You’ll be taken to a dashboard showing car details and its current location.

Notice the "Refresh Location" button. This button is likely linked to an API call that returns the current location of the associated vehicle.

Step 2: Intercept the "Refresh Location" Request

Open burpsuite on Kali (Applications > 01-Reconaissance > burpsuite).

If asked for a password enter: OW@sp1234!@#$

Inside burpsuite go to: Proxy > Intercept > Intercept on

Return to the app and click the "Refresh Location" button. burpsuite should now capture the outgoing request.

What you’re looking for:

• Endpoint URL (e.g., /api/vehicles/location)

• HTTP method (likely GET or POST)

• A parameter like vehicle_id in the request body or URL

Hint: If you miss the request, disable "Intercept", use burpsuite HTTP history (Proxy > HTTP history), and find the right request.

Step 3: Find Other Users' Vehicle IDs

With one valid vehicle_id in hand, consider how to find another user’s ID. Head back to the app and navigate to the Community section. This page seems to list posts made by other users.

Re-enable Intercept in burpsuite, Click on one of the posts—for instance, one by a user named "Robot".

This action triggers a request. Capture it, and then:

• Right-click the request > Send to Repeater

Go to the Repeater tab in burp suite, hit Send and study the response. You may see something like:

Now you have another user's vehicle_id.

Step 4: Exploit the BOLA Vulnerability

Time to determine whether the server enforces ownership validation:

1. Return to HTTP history in burpsuite and locate your original "Refresh Location" request.

2. Right-click > Send to Repeater

3. In Repeater, locate the parameter holding your own vehicle_id.

4. Replace that value with the other user’s vehicle_id discovered in Step 3.

5. Click Send and analyze the response.

If the server responds with location data for that ID, you've successfully accessed another user's vehicle info.

Result: BOLA Confirmed

Question: What are the last four characters of the Robot Vehicle ID?

Applications often use object identifiers like report_id to fetch user-specific resources. If the backend does not check whether the requesting user actually owns the requested object, attackers can simply change these IDs to access other users’ data.

Goal: Access mechanic reports that belong to other users by manipulating the report ID in an API request — revealing another BOLA (Broken Object Level Authorization) vulnerability.

Tools

burpsuite – You’ll again use this to intercept and modify HTTP requests.

You’ll mainly work with:

• Proxy tab to capture requests

• Repeater tab to edit and resend them

Important Note: Run the burpsuite before start the challenge ((Applications > 01-Reconaissance > burpsuite))

Tip: Leave Intercept off after capturing the request and use HTTP History to explore missed requests.

Step 1: Open the "Contact Mechanic" Page

Log into the crAPI web app (same as before), navigate to the "Contact Mechanic" page from the dashboard.

You’ll see a form asking for:

• VIN

• Mechanic

• Problem Description

Step 2: Submit a Mechanic Request

Now think like a penetration tester. You're not just using the app — you're watching how the app behaves in the background.

Here comes the interesting part...

Step 3: Intercept the Request with burpsuite

Open burpsuite, intercept the request, right-click -> Send To Repeater

In the Repeater tab click on the Send. You’ll see something like:

This request returns your mechanic report. But here’s the critical observation:

• The request includes only a simple numeric report_id

• There’s no session-specific token, no user validation, and no indication that the server is confirming that this report actually belongs to you

Step 4: Try Changing the Report ID

Inside the Repeater tab, change the POST request with below GET request and change the report_id parameter to other value and click Send - for excample:

GET /workshop/api/mechanic/mechanic_report?report_id=2

If the server responds with a different user’s mechanic report, you’ve confirmed a BOLA vulnerability again.

Result: BOLA Confirmed

Question: What is the email of the user who submited the report?

Broken Authentication refers to flaws in how an application manages user identity, session handling, and access control.

Goal: Determine if it’s possible to take over another user’s account by abusing the password reset system

Step 1: Initiate a Password Reset Request

Open your browser and navigate to the crAPI login page:

http://192.168.10.76:8888/login

Click the “Forgot Password” link.

Enter your own email "[email protected]" address, and the app will send a verification code (OTP) to the simulated mail server at:

http://192.168.10.76:8025

Step 2: Try Invalid OTPs

Enter invalid OTP, Intercept, Sned the Request to Repeater and click on Send many times. After a few clicks, the server replies: “You’ve exceeded the numbers of attempts.”

This shows that rate limiting (brute force protection) is in place — good for security... at least for this endpoint.

Step 3: Look for Legacy APIs

Here’s where things get interesting.When submitting the OTP, the request goes to:

We observe that this endpoint utilized version v3, ask yourself:
“Is there an older version of this endpoint still online, and does it have the same protections?”

Try sending the same request to:

/identity/api/auth/v2/check-otp

It accepts unlimited attempts — no rate-limiting, no lockout. That’s a major security flaw.This is an example of a Legacy API Exploit.

Step 4: Find Other Users' Emails

Go back to the Community page in crAPI.Use burpsuite > Proxy or HTTP History to inspect responses from forum posts.

Often, user data like this appears in responses:

 

Now you have a real target email to test.

Launch an OTP Brute-Force Attack with Burp Intruder

Time to use burpsuite - Intruder, a tool that lets you automate sending requests with different values.

Intruder Mode: Sniper

This mode tests a range of values in a single parameter.

What to do:

• Intercept a POST request to /api/v2/auth/check-otp

• Use the known target email (from Step 4)

• Identify the otp= field

• Set a payload position on the OTP value

• Set payloads from 0000 to 9999

Click Start Attack [This attack may take long time]

burp will try each OTP. When it gets the right one, the response will say:

"message" :"OTP verified"
"status" : 200

Excessive Data Exposure occurs when the backend includes more information than necessary in its responses

Even if the frontend hides it, it still reaches the browser (and any tool inspecting traffic).
That means any curious user can uncover private information just by looking at the response.

Goal: Determine whether the crAPI Community page returns sensitive or private data in its API response

Step-by-Step: Find the Leak

Go to the Community page in the crAPI app.

You’ll see forum posts, which look simple — just usernames and messages.

Now open:

• burpsuite > Proxy > HTTP History

Click on a original request. Look at the server’s full response.

You’ll likely see extra fields being returned — ones not shown in the WEB, like:

• email

• nickname

• vehicle_id

These are not meant to be visible to other users, but they're being leaked anyway.

You didn't even do anything malicious — you just viewed public content and observed the data sent by the server.

Question: Retrive the content that written by Pogba?

Internal Property Exposure occurs when backend systems include internal fields, configurations, or debug data in API responses that are meant to be used only internally

Goal: Explore whether the video upload feature in crAPI exposes backend processing logic or internal command parameters in its API response.

Step 1: Navigate to the Video Upload Feature

Open your brower and navigate to:

http://192.168.10.76:8888/my-profile

Click on upload video, start the burpsuite interception and upload the video. send the intercepted request to the Repeater.
Navigate to repeater tap and click to Send:

What’s the Vulnerability?

Let’s focus on this line:

"conversion_params": "-v codec h264"

This field shows the exact internal command used by the server to process the video — likely passed to a backend service like FFmpeg or a similar transcoder.

Question: What type of vulnerability does this challenge represent?

What Is Rate Limiting?

Rate limiting means restricting how many times a user can perform an action (like submitting a form) in a given time window.

What Is a Layer 7 DoS Attack?

Layer 7 = Application Layer (in the OSI model)

Unlike traditional DoS attacks that flood a server with junk traffic, a Layer 7 DoS uses legitimate-looking requests, but at very high volume, targeting server-side logic or processing power.

Example: Making thousands of requests to a form that does real work (like sending emails, storing data, or contacting support).

The Exploit: Burp Suite + Parameter Abuse

Goal: Discover an API endpoint that can be abused to trigger thousands of server-side executions

Step 1: Find the Vulnerable Feature

Go to the "Contact Mechanic" page in the crAPI.

There’s a form where users can send a service request.

When submitted, the backend processes the message and might even retry it if the first attempt fails. (Make sute the burpsuite API is on before submiting the request).

Go to intecepted request -> right-click -> Send To Repeater

Step 2: Notice the Replay Mechanism

Two important parameters:

• repeat_request_if_failed: Tells the server whether to retry if a request fails

• number_of_repeats: How many retry attempts to make

Step 3: Modify the Request to Trigger DoS

In the repeater tab. Change it to:

{
  "repeat_request_if_failed": true,
  "number_of_repeats": 10000
}

You're now saying:

“If the request fails... retry it 10,000 times.”

Click on the Send

But here’s the twist:

• Even if the request doesn’t fail, the app starts executing it thousands of times

• This behavior lacks safeguards, and the server starts looping through the request repeatedly

Result: Layer 7 Denial of Service

The server becomes overwhelmed handling all these repeated requests.

Eventually, it stops responding, and replies with:

This confirms the attack succeeded, and the challenge is complete.