Practice & Assessment
Test your understanding of Access Control and Authorization
Multiple Choice Questions
5A GET /api/documents/:id endpoint returns a 404 for documents that don't exist AND for documents the user doesn't own. Why is this better than returning 403 for unauthorized access?
An attacker sends `POST /register` with the body `{ "email": "attacker@example.com", "password": "password123", "role": "admin" }`. What prevents this from creating an admin account?
You spread `req.body` directly into a Mongoose update: `User.updateOne({ _id: id }, { $set: req.body })`. An attacker adds `"isAdmin": true` to the request body. Does Mongoose strict mode prevent this?
What is the difference between authentication and authorization middleware, and in which order must they run?
Using UUIDs instead of sequential integers for resource IDs fully mitigates IDOR vulnerabilities. True or false?
Coding Challenges
1Fix IDOR and Mass Assignment in a Notes API
You are given an Express + SQLite notes API with these endpoints: GET /notes/:id (no ownership check — returns any user's note), PUT /notes/:id (vulnerable to both IDOR and mass assignment via req.body spread), DELETE /notes/:id (no ownership check). Fix all three: (1) For GET and DELETE, add an ownership check that returns 404 (not 403) for both not-found and unauthorized. (2) For PUT, destructure only title and body from req.body and include the userId scope in the update query. (3) Write a Joi schema for the PUT body that strips any unknown fields. (4) Write supertest tests: user A cannot GET, PUT, or DELETE user B's note — each returns 404. Time estimate: 25–30 minutes.
Mini Project
Multi-Role Document Management API
Build a document management API with three roles: viewer, editor, and admin. Requirements: (1) POST /documents — editors and admins can create; viewers get 403. (2) GET /documents — viewers see only their own documents; editors see all; admins see all with user metadata. (3) PUT /documents/:id — editors can update only their own documents (ownership check + role); admins can update any. (4) DELETE /documents/:id — admin only. (5) POST /admin/assign-role — admin only endpoint that changes another user's role, but cannot assign a role higher than the actor's own role. (6) All endpoints use the authenticate + requirePermission middleware chain from lesson 5.5. (7) Log every role change and delete operation to a JSON audit log file with timestamp, actor ID, action, and target resource ID. Write supertest tests covering: viewer trying to create (403), editor trying to delete (403), editor updating another user's document (404), admin updating any document (200).