🖼️ See the drawing + lab 🏠 Course home 🌿 Branch on GitHub ✏️ View source

🖼️ आकृती आणि labThe drawing + lab पूर्ण पानावर उघडा ↗Open full page ↗

🚪 धडा 06 — Authorization आणि IDOR: काय करण्याची परवानगी, कोणत्या record वर

📍 तुम्ही इथे आहात: 16 पैकी धडा 06 · मागे: lesson-05-oauth-oidc · पुढे: lesson-07-secrets-kms

📦 या ब्रँचमध्ये काय आहे

धडे 01–05, आणि ओळखपत्र खिडकीचा शेवटचा धडा. एखादी व्यक्ती कोण आहे हे माहीत असल्याने ती काय करू शकते हे कळत नाही. तुम्ही RBAC (roles → permissions) लिहिता, मग ते पुरेसे का नाही ते पाहता: दीपिका पालक आहे, पालक grades वाचू शकतात — पण कोणाच्या grades? Object-level तपासणी याचे उत्तर देते, आणि IDOR / BOLA थांबवते. sec/demo.py मधले authz() हे दाखवते.

🧒 5 वर्षांच्या मुलाला समजावल्यासारखे

दीपिका पालक आहे. तिच्या badge वर PARENT लिहिले आहे. पालक प्रगतीपुस्तके पाहू शकतात. म्हणून records room तिला आत येऊ देते.

प्रगतीपुस्तके क्रमांक असलेल्या खणांमध्ये आहेत. दीपिका "aishwarya" खण मागते — तिच्या मुलीचा. ठीक आहे.

मग ती "katrina" खण मागते. तिच्या badge वर अजूनही PARENT आहे. कारकून फक्त badge पाहत असेल, तर तो खण उघडतो. हीच चूक आहे. Badge "पालक प्रगतीपुस्तके वाचू शकतात का?" याचे उत्तर देतो. "हे प्रगतीपुस्तक तिचे आहे का?" याचे उत्तर तो देत नाही.

म्हणून security office दुसरा प्रश्न जोडते, प्रत्येक खणासाठी, प्रत्येक वेळी: "या खणातली विद्यार्थिनी तुमच्या मुलांपैकी एक आहे का?" कतरिना दीपिकाची मुलगी नाही → खण बंदच राहतो.

🗺️ आकृती

flowchart LR
    d["👩 Dipika<br/>role: parent<br/>children: aishwarya"]
    d --> r1["GET /grades/aishwarya"]
    d --> r2["GET /grades/katrina"]
    r1 --> rb{"RBAC<br/>parent → grades:read?"}
    r2 --> rb
    rb -->|"yes for both"| obj{"object check<br/>pupil in her children?"}
    obj -->|"aishwarya: yes"| ok["✅ 200 — her daughter's record"]
    obj -->|"katrina: no"| no["❌ 404 — stops IDOR / BOLA"]

🗺️ काढलेली आवृत्ती + एक lab: https://school-edh.pages.dev/security/lesson-diagrams.html#l06

❓ काय

Authorization — authenticated user काय करू शकतो ते ठरवणे. इथल्या चुका म्हणजे A01:2021 – Broken Access Control, OWASP Top 10 (2021) मध्ये पहिल्या क्रमांकावर.
RBAC (role-based access control) — users ना roles मिळतात, roles ना permissions मिळतात. ROLES parent → {grades:read}, teacher → {grades:read, grades:write}, admin → {…, users:manage} असे जोडते. वाचायला आणि audit करायला सोपे. Default ने नकार: अनोळखी role ला काहीच मिळत नाही.
ABAC (attribute-based access control) — निर्णय user, resource आणि request च्या attributes वापरतो: owner, वर्ग, शाळा, दिवसाची वेळ. "Teacher स्वतःच्या वर्गासाठी grades लिहू शकते" हे ABAC आहे. जास्त अचूक, test करायला जास्त कठीण.
Object-level authorization — या record वरची तपासणी: हा user त्याचा मालक आहे का, किंवा त्याच्याशी त्याचे नाते आहे का? can_read_record() — पालक फक्त स्वतःच्या मुलांसाठी, teacher फक्त स्वतःच्या वर्गांसाठी.
IDOR (insecure direct object reference) / BOLA (broken object level authorization) — API client कडून id घेते (/grades/katrina, /invoices/1043) आणि object-level तपासणीशिवाय object परत देते. Id बदलला की दुसऱ्या कोणाचा data दिसतो. OWASP API Security Top 10 मध्ये BOLA API1:2023 आहे.
तपासणी कुठे राहते — server वर, एकाच ठिकाणी (policy function, query filter, किंवा database row-level security), प्रत्येक request साठी — updates, deletes, exports आणि "लपवलेले" admin endpoints सुद्धा.
404 की 403? — user ने पाहू नयेत अशा records साठी अनेक APIs 404 उत्तर देतात, म्हणजे record अस्तित्वात आहे हे उघड होत नाही.

🤔 का

कारण हा bug tests मधून सुटतो. त्यातली प्रत्येक request योग्यरित्या login केलेली असते, योग्य role असलेली असते, आणि खऱ्या endpoint वर जाते. फक्त id वेगळा असतो. Automated scanners ते क्वचितच शोधतात — record 1043 दुसऱ्या कोणाचा आहे हे त्यांना माहीत नसते. आणि ids बदलणे सोपे असते: URL मधला एक number, JSON मधले एक field, लपवलेली form value. Random ids (UUIDs) मुळे अंदाज करणे कठीण होते, पण ती तपासणी नाही.

🔧 कसे (या repo मध्ये)

sec/identity.py मध्ये: can(role, permission) permission ROLES मध्ये शोधते (अनोळखी role ला रिकामा set मिळतो). can_read_record(user, record) ही object-level तपासणी आहे: parent → record["pupil"] in user["children"]; teacher → record["class"] in user["classes"]; फक्त admin ला सगळे दिसते. sec/demo.py मधले authz() दोन्ही requests साठी RBAC पास होताना, आणि object तपासणी निर्णय घेताना दाखवते.

🧪 करून पाहा

python3 sec/demo.py authz
python3 - <<'EOF'
import sys; sys.path.insert(0, "sec"); from identity import can, can_read_record
people = {"Dipika (parent)": dict(role="parent", children={"aishwarya"}),
          "teacher of 3A": dict(role="teacher", classes={"3A"}),
          "teacher of 4B": dict(role="teacher", classes={"4B"}),
          "office admin": dict(role="admin")}
records = [dict(pupil="aishwarya", **{"class": "3A"}), dict(pupil="katrina", **{"class": "4B"})]
for who, u in people.items():
    rows = " · ".join(f"{r['pupil']} {can_read_record(u, r)}" for r in records)
    print(f"{who:<16} grades:read {can(u['role'], 'grades:read')!s:<5} → {rows}")
print("unknown role 'visitor' grades:read →", can("visitor", "grades:read"))
EOF

✅ तपासा — तुम्हाला काय दिसायला हवे

authz हे print करते:

── RBAC: parent may grades:read True · grades:write False · teacher grades:write True
── GET /grades/{id}: the role check passes for both — the OBJECT check is what matters
   Dipika (parent of Aishwarya) reads Aishwarya's record → True
   Dipika changes the id in the URL to Katrina's record  → False  (without this check: IDOR / BOLA)
   check ownership on the server for every object, every time — never trust an id from the client

तुमचा snippet हे print करतो:

Dipika (parent)  grades:read True  → aishwarya True · katrina False
teacher of 3A    grades:read True  → aishwarya True · katrina False
teacher of 4B    grades:read True  → aishwarya False · katrina True
office admin     grades:read True  → aishwarya True · katrina True
unknown role 'visitor' grades:read → False

🏁 तुम्ही आत्ताच काय सिद्ध केले

चारही users role तपासणी पास करतात — role column प्रत्येकासाठी True म्हणतो. त्यांना वेगळे करते ती object तपासणी: प्रत्येक teacher ला फक्त स्वतःचा वर्ग दिसतो, पालकाला फक्त तिचे स्वतःचे मूल. RBAC "कोणत्या प्रकारची कृती" याचे उत्तर देते; object तपासणी "कोणत्या record वर" याचे उत्तर देते. API ला दोन्ही लागतात.

⚠️ नेहमीच्या चुका

URL मधल्या id सह SELECT * FROM grades WHERE id = ? — आणि दुसरे काहीच नाही
GET वर ownership तपासणे, पण PUT, DELETE किंवा CSV export वर नाही
UI मधले button लपवणे आणि त्याला "access control" म्हणणे
request body मध्ये पाठवलेल्या user_id किंवा role field वर विश्वास ठेवणे
प्रत्येक staff member साठी एकच प्रचंड admin role, कारण roles कधी विभागलेच नाहीत
एकमेव संरक्षण म्हणून random ids (UUIDs)

🏭 प्रत्यक्ष वापरात

खऱ्या account वर — ownership query मध्येच ठेवा, म्हणजे नसलेला record आणि मनाई असलेला record सारखेच दिसतात (Python + psycopg):

cur.execute("""
    SELECT g.subject, g.grade FROM grades g
    JOIN guardians gu ON gu.pupil_id = g.pupil_id
    WHERE g.pupil_id = %s AND gu.parent_id = %s""", (pupil_id, current_user.id))
rows = cur.fetchall()
if not rows: abort(404)

Django ORM सह हेच — filter मध्ये प्रत्येक वेळी user असतो:

grade = get_object_or_404(Grade, pk=pk, pupil__guardians__user=request.user)

किंवा PostgreSQL row-level security ने database लाच हे enforce करू द्या — विसरलेला filter सुद्धा दुसऱ्या कुटुंबाच्या rows परत देऊ शकत नाही:

ALTER TABLE grades ENABLE ROW LEVEL SECURITY;
CREATE POLICY parent_reads_own ON grades FOR SELECT
  USING (pupil_id IN (SELECT pupil_id FROM guardians
                      WHERE parent_id = current_setting('app.user_id')::int));
-- at the start of each request, in the same transaction, the app runs:
--   SELECT set_config('app.user_id', %s, true)   with the user id as a bound parameter

तपासणी अस्तित्वात आहे हे सिद्ध करणारी test (pytest) — एक user, दुसऱ्या user चा id:

def test_parent_cannot_read_other_pupil(client, login_as):
    login_as("dipika")
    assert client.get("/grades/aishwarya").status_code == 200
    assert client.get("/grades/katrina").status_code == 404

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे: object तपासणी विसरणे अशक्य करा — नेहमी सध्याचा user घेणारी repository method, किंवा row-level security — आणि id घेणाऱ्या प्रत्येक endpoint साठी एक "दुसऱ्या user चा id" test जोडा. अनेक services मध्ये बारीक ABAC साठी, policy engine (Open Policy Agent, Cedar / Amazon Verified Permissions) नियम एकाच test केलेल्या ठिकाणी ठेवते.

⏭️ पुढे

ओळखपत्र खिडकी पूर्ण झाली. आता इमारत खिडकी: पूर्ण इमारतीच्या किल्ल्या. Database passwords आणि encryption keys कुठे राहतात — आणि code मध्ये कधीच का नाहीत?

git checkout lesson-07-secrets-kms

🚪 Lesson 06 — Authorization and IDOR: allowed to do WHAT, to WHICH record

📍 You are here: Lesson 06 of 16 · Previous: lesson-05-oauth-oidc · Next: lesson-07-secrets-kms

📦 What's in this branch

Lessons 01–05, plus the last lesson of the ID desk. Knowing who someone is does not say what they may do. You write RBAC (roles → permissions), then see why it is not enough: Dipika is a parent, parents may read grades — but whose grades? The object-level check answers that, and stops IDOR / BOLA. authz() in sec/demo.py shows it.

🧒 Explain like I'm 5

Dipika is a parent. Her badge says PARENT. Parents may look at report cards. So the records room lets her in.

The report cards are in drawers with numbers. Dipika asks for drawer "aishwarya" — her daughter's. Fine.

Then she asks for drawer "katrina". Her badge still says PARENT. If the clerk only looks at the badge, he opens the drawer. That is the mistake. The badge answers "may parents read report cards?". It does not answer "is this report card hers?".

So the security office adds a second question, for every drawer, every time: "Is the pupil in this drawer one of your children?" Katrina is not Dipika's child → the drawer stays closed.

🗺️ Diagram

flowchart LR
    d["👩 Dipika<br/>role: parent<br/>children: aishwarya"]
    d --> r1["GET /grades/aishwarya"]
    d --> r2["GET /grades/katrina"]
    r1 --> rb{"RBAC<br/>parent → grades:read?"}
    r2 --> rb
    rb -->|"yes for both"| obj{"object check<br/>pupil in her children?"}
    obj -->|"aishwarya: yes"| ok["✅ 200 — her daughter's record"]
    obj -->|"katrina: no"| no["❌ 404 — stops IDOR / BOLA"]

🗺️ Drawn version + a lab: https://school-edh.pages.dev/security/lesson-diagrams.html#l06

❓ What

Authorization — deciding what an authenticated user may do. Failures are A01:2021 – Broken Access Control, number one in the OWASP Top 10 (2021).
RBAC (role-based access control) — users get roles, roles get permissions. ROLES maps parent → {grades:read}, teacher → {grades:read, grades:write}, admin → {…, users:manage}. Simple to read and to audit. Deny by default: an unknown role gets nothing.
ABAC (attribute-based access control) — the decision uses attributes of the user, the resource and the request: owner, class, school, time of day. "A teacher may write grades for their own class" is ABAC. More precise, harder to test.
Object-level authorization — the check on this record: does this user own it, or have a relationship to it? can_read_record() — a parent only for their own children, a teacher only for their own classes.
IDOR (insecure direct object reference) / BOLA (broken object level authorization) — an API takes an id from the client (/grades/katrina, /invoices/1043) and returns the object without the object-level check. Changing the id shows someone else's data. BOLA is API1:2023 in the OWASP API Security Top 10.
Where the check lives — on the server, in one place (a policy function, a query filter, or database row-level security), for every request — including updates, deletes, exports and "hidden" admin endpoints.
404 or 403? — for records the user must not see, many APIs answer 404, so they do not reveal that the record exists.

🤔 Why

Because this is the bug that tests miss. Every request in it is correctly logged in, has the right role, and hits a real endpoint. Only the id is different. Automated scanners rarely find it — they do not know that record 1043 belongs to someone else. And ids are easy to change: a number in a URL, a field in JSON, a hidden form value. Random ids (UUIDs) make guessing harder, but they are not a check.

🔧 How (in this repo)

In sec/identity.py: can(role, permission) looks the permission up in ROLES (an unknown role gets an empty set). can_read_record(user, record) is the object-level check: parent → record["pupil"] in user["children"]; teacher → record["class"] in user["classes"]; only admin sees all. authz() in sec/demo.py shows RBAC passing for both requests, and the object check deciding.

🧪 Try it

python3 sec/demo.py authz
python3 - <<'EOF'
import sys; sys.path.insert(0, "sec"); from identity import can, can_read_record
people = {"Dipika (parent)": dict(role="parent", children={"aishwarya"}),
          "teacher of 3A": dict(role="teacher", classes={"3A"}),
          "teacher of 4B": dict(role="teacher", classes={"4B"}),
          "office admin": dict(role="admin")}
records = [dict(pupil="aishwarya", **{"class": "3A"}), dict(pupil="katrina", **{"class": "4B"})]
for who, u in people.items():
    rows = " · ".join(f"{r['pupil']} {can_read_record(u, r)}" for r in records)
    print(f"{who:<16} grades:read {can(u['role'], 'grades:read')!s:<5} → {rows}")
print("unknown role 'visitor' grades:read →", can("visitor", "grades:read"))
EOF

✅ Verify — what you should see

authz prints:

── RBAC: parent may grades:read True · grades:write False · teacher grades:write True
── GET /grades/{id}: the role check passes for both — the OBJECT check is what matters
   Dipika (parent of Aishwarya) reads Aishwarya's record → True
   Dipika changes the id in the URL to Katrina's record  → False  (without this check: IDOR / BOLA)
   check ownership on the server for every object, every time — never trust an id from the client

Your snippet prints:

Dipika (parent)  grades:read True  → aishwarya True · katrina False
teacher of 3A    grades:read True  → aishwarya True · katrina False
teacher of 4B    grades:read True  → aishwarya False · katrina True
office admin     grades:read True  → aishwarya True · katrina True
unknown role 'visitor' grades:read → False

🏁 What you just proved

All four users pass the role check — the role column says True for everyone. The object check is what separates them: each teacher sees only their own class, the parent only her own child. RBAC answers "what kind of action"; the object check answers "on which record". An API needs both.

⚠️ Common mistakes

SELECT * FROM grades WHERE id = ? with the id from the URL — and nothing else
checking ownership on GET, but not on PUT, DELETE or the CSV export
hiding a button in the UI and calling that "access control"
trusting a user_id or role field sent in the request body
one huge admin role for every staff member, because roles were never split
random ids (UUIDs) as the only protection

🏭 In production

On a real account — put the ownership into the query, so a missing record and a forbidden record look the same (Python + psycopg):

cur.execute("""
    SELECT g.subject, g.grade FROM grades g
    JOIN guardians gu ON gu.pupil_id = g.pupil_id
    WHERE g.pupil_id = %s AND gu.parent_id = %s""", (pupil_id, current_user.id))
rows = cur.fetchall()
if not rows: abort(404)

The same with the Django ORM — the filter includes the user, every time:

grade = get_object_or_404(Grade, pk=pk, pupil__guardians__user=request.user)

Or let the database enforce it with PostgreSQL row-level security — even a forgotten filter cannot return another family's rows:

ALTER TABLE grades ENABLE ROW LEVEL SECURITY;
CREATE POLICY parent_reads_own ON grades FOR SELECT
  USING (pupil_id IN (SELECT pupil_id FROM guardians
                      WHERE parent_id = current_setting('app.user_id')::int));
-- at the start of each request, in the same transaction, the app runs:
--   SELECT set_config('app.user_id', %s, true)   with the user id as a bound parameter

A test that proves the check exists (pytest) — one user, another user's id:

def test_parent_cannot_read_other_pupil(client, login_as):
    login_as("dipika")
    assert client.get("/grades/aishwarya").status_code == 200
    assert client.get("/grades/katrina").status_code == 404

🏭 Why this matters in production: make the object check impossible to forget — a repository method that always takes the current user, or row-level security — and add one "other user's id" test for every endpoint that takes an id. For fine-grained ABAC across many services, a policy engine (Open Policy Agent, Cedar / Amazon Verified Permissions) keeps the rules in one tested place.

⏭️ Next

The ID desk is done. Now the building desk: the keys to the whole building. Where do database passwords and encryption keys live — and why never in the code?

git checkout lesson-07-secrets-kms

← Previousoauth oidc Next →secrets kms

This page is the lesson's README from the lesson-06-authorization branch, shown here so the whole School stays on one site. Code files open on GitHub at the same branch.