CSRF and IDOR

CSRF: riding on a logged-in session

Cross-site request forgery (CSRF) abuses the fact that a browser automatically sends your cookies with every request to a site. If you are logged in to your bank and then visit a malicious page, that page can quietly make your browser send a request to the bank — say, a transfer — and your cookie rides along, so the bank thinks you meant it.

• Fix: anti-CSRF tokens — a secret, per-session value the server includes in its forms and checks on submission. A malicious site cannot know the token, so its forged request fails.
• Fix: SameSite cookies — set cookies to SameSite=Lax or Strict so the browser does not send them on cross-site requests.
• Detection: requests that change state but lack a valid token, or come with an unexpected Origin/Referer.

IDOR: changing the ID

Insecure direct object reference (IDOR) is a kind of broken access control. The app uses an identifier (like ?id=7) to fetch a record, but does not check that the record belongs to the logged-in user. Change 7 to 8 and you see someone else's data. It is one of the most common and serious real-world flaws, and one of the easiest to find — which you did in the Burp lesson.

// Vulnerable: returns any order by id
app.get('/api/orders/:id', requireLogin, async (req, res) => {
  res.json(await db.getOrder(req.params.id));
});

// Fixed: check the order belongs to this user
app.get('/api/orders/:id', requireLogin, async (req, res) => {
  const order = await db.getOrder(req.params.id);
  if (!order || order.userId !== req.user.id) return res.status(404).end();
  res.json(order);
});

Detection and defence

Detection for IDOR: logs showing one account accessing many different record IDs, especially sequential ones. Defence: enforce access control on the server for every object, every time; never rely on the ID being hard to guess; and consider using identifiers that are not sequential (like random UUIDs) as a small extra hurdle — but the real fix is always the ownership check.