KB / Статті / IDOR та Mass Assignment: зламати авторизацію об'єктів
UA EN

IDOR & Mass Assignment: Breaking Object Authorization

✍ admin 📅 21.09.2026 👁 27 переглядів

Broken Access Control

Both bugs are A01: Broken Access Control — #1 in the OWASP Top 10. The essence: the server trusts the client where it should check permissions.

IDOR (Insecure Direct Object Reference)

The app takes an object identifier straight from the request and returns the object without checking the user is allowed to see it.

GET /api/invoices/1043     → your invoice
GET /api/invoices/1044     → someone else's (!)

How to find: any id, user_id, uuid, filename in the URL, params, body or cookies. Iterate, substitute other values, diff responses. UUIDs don't help if you can learn them elsewhere. Why it happens: the dev checked authentication but not authorization (is it your object).

Mass Assignment

Frameworks often auto-map request fields onto model fields. Done blindly, an attacker sends extra fields they shouldn't control:

POST /api/profile
{"display_name": "Bob", "role": "admin"}   ← role shouldn't be editable

The server copies every field → you're admin. Classic privilege escalation. How to find: add fields like role, is_admin, verified, user_id and see if they stick.

Defense

  • IDOR: on every request verify the object belongs to the current user (WHERE id=? AND owner_id=current_user). Don't rely on ID unpredictability.
  • Mass Assignment: use an allow-list of fields (binding whitelist / DTO / explicit serializer). Never user.update(**request.json).
  • Test authorization separately from authentication.

Practice: BankApp: JWT + IDOR + Mass Assignment and the Meridian capstone.

Коментарі (0)
Увійди, щоб залишити коментар.
Коментарів поки немає.
Вперше тут?
Новачок на Bastion?
Почни з гайду користувача.
Відкрити гайд →
?