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 handlers 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.
-
go run ./cmd/seed go run ./cmd/server
With Bearly Secure still running, run and submit the CLI tests from the project root.