IDOR & Parameter Tampering

Understanding Insecure Direct Object References, broken access control, and secure web application design.

⌄

Introduction

One of the most dangerous and common web vulnerabilities is broken access control. Two major examples are IDOR vulnerabilities and parameter tampering.

These issues happen when applications trust data coming from the browser without properly validating authorization on the server side.

Important: Frontend validation is not security. Users can manipulate requests, forms, cookies, APIs, and URLs.

What is IDOR?

IDOR stands for Insecure Direct Object Reference. It happens when an application exposes internal identifiers such as account IDs, filenames, or database records without properly checking permissions.

Example Vulnerable URL

https://example.com/account?user_id=123

If changing the ID from 123 to 124 exposes another user's account, the application is vulnerable.

The problem is not that the ID is visible. The problem is that the server trusted the client request.

What is Parameter Tampering?

Parameter tampering occurs when users manipulate values exchanged between the client and the server.

Price Manipulation

https://shop.com/pay?price=5

If changing the price to 1 changes the final cost, the application trusts user input.

Privilege Escalation

https://site.com/panel?role=user

Changing role=user to role=admin should never grant privileges.

Why These Vulnerabilities Exist

Developers sometimes assume users only interact with websites through the intended interface. 

if (userCanSeeButton) {
   // secure
}

Attackers can directly modify requests using:

The browser belongs to the user, not the server.

Real World Examples

File Download Exposure

/download?file=invoice_123.pdf

Modifying the filename could expose confidential documents.

API Authorization Failure

GET /api/users/42/profile

If another user can access the resource by changing the number, authorization checks are missing.

Admin Panel Abuse

/admin/deleteUser?id=15

If normal users can modify IDs and delete records, the system is critically insecure.

How to Prevent IDOR

1. Validate Authorization Server-Side

app.get("/profile/:id", (req, res) => {

   if(req.user.id !== req.params.id){
      return res.status(403).send("Forbidden");
   }

   const profile = db.getUser(req.params.id);

   res.send(profile);

});

Every request must verify:

  • Who is making the request
  • What resource is requested
  • Whether access is allowed

2. Use Sessions Instead of URL Identity

/profile

Derive identity from the authenticated session, not from user-controlled parameters.

3. Never Trust Hidden Fields

<input type="hidden" name="price" value="5">

Hidden fields are editable. Sensitive values must be validated server-side.

4. Use UUIDs

/user/550e8400-e29b-41d4-a716-446655440000

Random identifiers reduce predictable enumeration, although authorization checks are still mandatory.

5. Secure APIs

Many modern vulnerabilities happen because APIs are forgotten while only the frontend is protected.

Better Secure Design Alternatives

Sessions

Store identity server-side instead of exposing user IDs.

Signed URLs

Useful for temporary downloads, password resets, and protected resources.

Access Tokens

APIs should validate scoped access tokens server-side.

Role Based Access Control

Centralized authorization systems are safer than frontend restrictions.

Common Misconceptions

  • "The button is hidden."
  • "Users cannot edit hidden fields."
  • "The ID is random enough."
  • "Only admins know the URL."

Security through obscurity is not enough. Authorization must be enforced on every request.

Key Security Principle

Never Trust the Client

Users can manipulate:

  • URLs
  • Cookies
  • Forms
  • Headers
  • JavaScript
  • API Requests

The server must independently validate authorization.

Final Thoughts

IDOR and parameter tampering vulnerabilities remain common because developers accidentally trust user-controlled input.

Secure applications validate authorization everywhere, not just in the frontend.

A secure system assumes every request can be manipulated.

Video Reference

This video provides an excellent explanation of broken access control and IDOR vulnerabilities.