This lesson's interactive features are locked, please to keep using them

Principle of Least Privilege

In web security, you're gonna hear about the principle of least privilege all the time. In basic terms:

Give users and systems only the access they need and nothing more.

Every permission is a potential liability. Over-privileged accounts can turn small mistakes into major breaches.

Sources of Over-Privilege

Most systems don't start over-privileged; they become that way over time, often due to laziness or convenience:

Roles growing without review
Copying permissions from "admin" to save time
Combining unrelated responsibilities into a single role
Giving new users bigger roles than they need to avoid friction

Least Privilege in Practice

Permissions should be:

Explicit: every permission is intentionally granted, not inherited or assumed
Minimal: only what the role actually needs to function
Reviewed regularly: permissions that aren't audited will drift over time

Don't grant a permission just because it might be useful later. Ask one question for every permission:

What breaks if this permission is removed?

"Nothing"? Remove it.

Assignment

Bearly Secure's product edit and update routes give support agents access to product editing and internal cost data. Support agents don't need either permission to help customers. Restrict product editing to administrators.

In src/routes/admin.ts, restrict both product-management routes to only admins (remove "support" from the allowed roles):
- GET /admin/products/:id/edit
- POST /admin/products/:id
Reset the database and start the app:
```
npm run db:reset
npm run dev
```
Log in as support agent Sancho Panza ([email protected] / password123) and confirm /admin/products/1/edit returns 403 Forbidden.
Log in as administrator Theo Beers ([email protected] / password123) and confirm the same page still works.

With Bearly Secure still running, run and submit the CLI tests from the project root.