Posted inSecurity

Beyond the Firewall: Stopping Mass Assignment and IDOR in Modern APIs

Security tutorial - IT technology blog
Security tutorial - IT technology blog

The 2:15 AM Wake-Up Call: A Mass Assignment Post-Mortem

My PagerDuty alert didn’t just chirp; it screamed. At 2:15 AM, our Datadog dashboard showed 450 unauthorized ‘role’ modifications in under three minutes. By the time I opened my laptop, a trial user had already promoted themselves to ‘superuser’ and started exfiltrating 15,000 customer records. The attack didn’t use a fancy zero-day or complex SQL injection. It was a simple Mass Assignment vulnerability hidden in a profile update endpoint.

Think of Mass Assignment as an “over-sharing” problem. It happens when an application takes raw user input and binds it directly to an internal database model without filtering. If your backend logic looks like User.update(req.body), you have effectively given every API consumer write-access to your entire schema. An attacker just appends "is_admin": true to their JSON payload, and your database happily complies.

IDOR (Insecure Direct Object Reference) is its equally dangerous cousin. This occurs when an app trusts user input to fetch specific records. If I can swap /api/orders/1024 for /api/orders/1025 and view your private invoice, your authorization logic is broken. Both flaws represent a failure in Object-Level Access Control (OLAC)—the practice of verifying not just who a user is, but what specific data they can touch.

Deconstructing the Attack Surface

In the incident I managed, the developer used a modern ORM to speed up the MVP. The logic seemed sound: “The user is logged in, so they can update their own profile.” However, this ignored the gap between Authentication (proving identity) and Authorization (verifying permissions for a specific resource).

Security starts with the basics, even in a crisis. While setting up the staging environment for this fix, I generated new server secrets using the tool at toolcraft.app/en/tools/security/password-generator. Since it runs entirely in the browser, no sensitive strings ever hit the wire. It’s a small, clean habit that pays off when the pressure is high.

The Lab: Building a Vulnerable API

To fix a leak, you have to see where the water is coming from. Below is a stripped-down Node.js environment that mirrors the flaws we found in production. You can run this on any machine with Node.js installed.

# Setup the environment
mkdir security-lab && cd security-lab
npm init -y
npm install express

Create app.js with the code below. This represents the typical “move fast and break things” approach that leads to security debt:

const express = require('express');
const app = express();
app.use(express.json());

// Mock Database
let users = {
    "1": { id: 1, username: "alice", role: "user", bio: "Hello!" },
    "2": { id: 2, username: "bob", role: "user", bio: "I love security." }
};

// VULNERABLE: Mass Assignment
app.put('/api/profile', (req, res) => {
    const userId = "1"; // Mocking the session user
    // The flaw: blindly merging req.body into our database object
    Object.assign(users[userId], req.body);
    res.send({ message: "Profile updated", user: users[userId] });
});

// VULNERABLE: IDOR
app.get('/api/orders/:id', (req, res) => {
    const orderId = req.params.id;
    // The flaw: No check to see if orderId belongs to the requester
    res.send({ orderId: orderId, data: "Sensitive Invoice Data for ID " + orderId });
});

app.listen(3000, () => console.log('Vulnerable server on port 3000'));

The Fix: Implementing Object-Level Access Control

Plugging these holes requires us to stop prioritizing developer convenience over data integrity. We need two things: strict allow-listing for updates and ownership verification for data access.

Securing Updates with Data Transfer Objects (DTOs)

Never let req.body touch your database directly. Instead, explicitly extract the fields you want to allow. This simple change makes it impossible for an attacker to inject a role or balance field into the update query.

// SECURE: Manual Allow-listing
app.put('/api/profile/secure', (req, res) => {
    const userId = "1"; 
    const { bio, location } = req.body; // Only extract what is safe
    
    if (bio) users[userId].bio = bio;
    if (location) users[userId].location = location;
    
    res.send({ message: "Update successful", user: users[userId] });
});

Stopping IDOR with Ownership Middleware

To defeat IDOR, every request for a resource must be gated. You must verify that the authenticated User ID matches the owner_id of the requested resource in your database.

// SECURE: Ownership Verification
const verifyOwnership = (req, res, next) => {
    const currentUserId = 1; // Pulled from your JWT or Session
    const requestedOrderId = req.params.id;
    
    // Real-world: const order = await db.orders.findById(requestedOrderId);
    const orderOwnerId = 2; // Let's assume order 101 belongs to Bob (ID 2)

    if (currentUserId !== orderOwnerId) {
        return res.status(403).json({ error: "Access Denied: You do not own this resource" });
    }
    next();
};

app.get('/api/orders/secure/:id', verifyOwnership, (req, res) => {
    res.send({ orderId: req.params.id, data: "Secure Invoice Data" });
});

Validation: Testing the Defenses with Postman

Once your fixes are live, you need to prove they work. Automated security tests in Postman are the best way to prevent these vulnerabilities from creeping back into your codebase during future sprints.

Verifying the Mass Assignment Shield

  1. Target the PUT endpoint at http://localhost:3000/api/profile/secure.
  2. Set the body to JSON.
  3. Attempt an exploit: { "bio": "Hacked", "role": "admin" }.
  4. Submit the request.

The response should show the bio changed, but the role should remain user. The API successfully ignored the unauthorized field.

Verifying the IDOR Shield

  1. Send a GET request to http://localhost:3000/api/orders/secure/101.
  2. Because our middleware simulates a mismatch (Alice trying to see Bob’s data), the server must return a 403 Forbidden.

Watching for Red Flags

Detection is just as vital as prevention. You need to know when someone is probing your perimeter. I recommend monitoring two specific metrics:

  • 403 Forbidden Spikes: If a single IP hits 20 different resource IDs and triggers 403 errors within 60 seconds, they are likely running an IDOR enumeration script.
  • Schema Violations: Use a library like Zod or Joi. Log every instance where a user sends a field that isn’t in your schema. Seeing permissions or is_admin in a logs is a high-fidelity indicator of an active attack.

I usually pipe these events into a Slack alert. If the threshold is crossed, our WAF automatically drops the connection. It’s the only way to ensure that 2:15 AM pager call never happens again.

Share:
Tags: