و الصلاة و السلام على أشرف الخلق أجمعين سيدنا و حبيبنا و شفيعنا محمد صلى الله عليه و سلم

رمضان مبارك علينا و عليكم تقبل الله منا و منكم الصيام و القيام و جعلنا من عتقاء هذا الشهر الكريم اللهم امييين

اللهم لا علم لنا إلا ما علمتنا إنك أنت العليم الحكيم

Hello Hunters, This is a new Write up about another exiting finding ,Its about How A Critical IDOR Vulnerability Allowed Deletion & Modification of (Any) User's Address.

Lets start …

Introduction

In modern web applications, authorization flaws remain one of the most dangerous yet commonly overlooked vulnerabilities. Among them, Insecure Direct Object Reference (IDOR) — or more formally, Broken Object Level Authorization (BOLA) — can lead to devastating consequences when sensitive user-controlled identifiers are not properly validated.

In this write-up, I will walk through a critical IDOR vulnerability that allowed:

  • Unauthorized modification of other users' data
  • Permanent deletion of victim addresses
  • Mass exploitation due to predictable identifiers

This issue demonstrates how a seemingly simple flaw can escalate into a platform-wide integrity compromise.

Vulnerability Overview

The application exposes a feature that allows authenticated users to manage their saved addresses:

https://example.com/adresses

While interacting with this functionality, it was discovered that:

  • Each address is identified using a numeric id_address
  • Each user is identified with id_customer
  • Both values are sequential and predictable
  • The backend fails to validate ownership of the address

This results in a classic IDOR / BOLA vulnerability.

Technical Details

Test Setup

Two accounts were created:

Attacker Account:

id_customer = 45230
id_address  = 46061

Victim Account:

id_customer = 45231
id_address  = 46063

Browser isolation was achieved using tools like PwnFox to simulate separate sessions.

Vulnerable Request

When updating an address, the application sends the following request:

POST /adresse?id_address=46061 HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Cookie: session=ATTACKER_SESSION
id_address=46061&id_customer=45230&alias=Home&firstname=Test&lastname=User&address1=test&postcode=11111&city=test&id_country=8&submitAddress=1

Exploitation

The vulnerability arises because the server trusts user-supplied identifiers.

By modifying both instances of id_address:

POST /adresse?id_address=46063 HTTP/1.1
Host: example.com
id_address=46063&id_customer=45230&...

Where:

  • 46063 belongs to the victim

Impact

This simple modification resulted in:

- Unauthorized Actions

  • Deletion of the victim's address
  • Overwriting victim data

- Data Reassignment

  • The deleted address ID (46063) was reassigned to the attacker

- Mass Exploitation Potential

Because:

  • IDs are sequential
  • No authorization checks exist

An attacker can:

  • Enumerate all id_address values
  • Systematically delete or modify all user addresses

Business Impact

This vulnerability is critical due to:

  • Data Integrity Loss: Users lose saved addresses permanently
  • Account Data Corruption: Unauthorized modifications
  • Trust Damage: Users cannot rely on stored data
  • Scalability of Attack: Entire user base can be targeted

In real-world scenarios, this could lead to:

  • Order delivery disruptions
  • Fraud scenarios
  • Customer churn and reputational damage

Rewarded

None

Real Bounty Comparison (€500 vs Industry)

To objectively evaluate the reward, let's compare with real-world IDOR payouts:

Industry Data

  • Average IDOR bounty: ~$1,285 (~€1,200)

High-impact IDORs:

$3,500 (banking data exposure)

$10,500 (account-level abuse)

$12,500 (critical platform manipulation)

Real disclosed case:

Platform Benchmarks

  • Typical High severity range:
  • $1,000 — $5,000+

Critical severity:

  • Can exceed $10,000+

Root Cause Analysis

The issue stems from:

- Missing Authorization Checks

The server does not verify:

Does this address belong to the authenticated user?

- Trust in Client Input

Critical identifiers are fully user-controlled:

  • id_address
  • id_customer

- Predictable Identifiers

Sequential numeric IDs make enumeration trivial.

Vulnerability Classification

  • Type: IDOR (Insecure Direct Object Reference)
  • OWASP Category: Broken Object Level Authorization (BOLA)
  • OWASP Top 10: A01: Broken Access Control

Recommended Fix

- Enforce Ownership Validation

On every request:

if address.user_id != current_user.id:
    deny_access()

- Remove Trust from Client Input

  • Do NOT rely on id_customer from user requests
  • Derive user identity from session/authentication context

- Use Indirect References

Replace sequential IDs with:

  • UUIDs
  • Random tokens

- Implement Access Control Middleware

Centralize authorization checks across endpoints.

- Logging & Monitoring

Detect:

  • Repeated ID enumeration
  • Suspicious modification patterns

Final Thoughts

This vulnerability highlights a critical lesson:

"Authentication alone is not security — authorization is mandatory"

Even with valid sessions, users must only access resources they own.

IDOR vulnerabilities are often easy to exploit but extremely impactful — making them a top priority for both attackers and defenders.

Thanks for reading. And i hope that you learned something new.

If you wanna following me on social media :-

https://t.me/wadgamaraldin (Telegram Channel For — Writeups — Blogs — Bug Bounty Tips — YouTube Videos )

https://www.linkedin.com/in/wadgamaraldeen/

https://twitter.com/wadgamaraldeen/

https://www.facebook.com/wadgamaraldeen/

About Me

Mustafa Adam

Bug Bounty Hunter

  • HackerOne / Zerocopoter / Standoff365 / Google VRP / Private Programs
  • Focus: Web Application Security