What is Principle of Least Privilege?

Deciding the blast radius in advance

Assume something will eventually go wrong: a password leaks, a plugin ships a vulnerability, a laptop disappears from a café. Least privilege does not stop those events. It decides how much damage they can do. If the compromised account could only read the orders table, the attacker does not get customer password hashes or payment settings along with it.

NIST's glossary definition puts it plainly: a system should restrict the access privileges of users, or processes acting on behalf of users, to the minimum necessary to accomplish assigned tasks. The word “processes” matters. The principle covers service accounts, scheduled jobs, CI/CD pipelines and AI agents just as much as people.

Where it shows up in a typical web stack

• Databases: the application connects with a dedicated user that can read and write only the tables it uses, not with an admin account that can drop tables or alter the schema. Migrations run under a separate account.
• API keys and tokens: an API key is issued with the narrowest scope available, for one environment and with a limited lifetime. An integration that only lists products has no business cancelling orders.
• CMS roles: an editor who writes articles cannot install plugins or manage users. The WordPress Administrator role goes only to people who actually run the site.
• Server processes: the web server runs as an unprivileged system user, not as root, with write access limited to upload and cache directories.
• Cloud and deployment: the service account that deploys the app can touch the resources it deploys to and nothing else: no billing, no identity management.

A concrete example: separate database roles

-- Day-to-day application access
CREATE ROLE app_rw LOGIN PASSWORD '...';
GRANT SELECT, INSERT, UPDATE ON orders, order_items TO app_rw;
GRANT SELECT ON products TO app_rw;

-- The reporting tool can only read
CREATE ROLE reporting_ro LOGIN PASSWORD '...';
GRANT SELECT ON orders, products TO reporting_ro;

If the reporting tool's credentials leak, nothing can be modified. If the application account is taken over, tables still cannot be dropped and ungranted tables stay unreadable. Keeping those passwords out of source code in the first place is the job of secrets management.

Privilege creep and how to stop it

Permissions are easy to grant and rarely revoked. An admin right handed out for an urgent fix stays for months, a former agency's account is never closed, a broadly scoped test token quietly ends up in production. This slow accumulation, known as privilege creep, is how least privilege usually erodes in practice. Countermeasures that work:

• Review access on a schedule and remove accounts and keys nobody uses.
• Prefer just-in-time access, where elevated rights are granted on request and expire automatically, over permanent admin roles.
• Keep access traceable through logging, so that during an incident you can quickly answer which account could reach what.

What least privilege is not

It is not the same as strong login security. Authentication answers “who are you?”, while authorization answers “what may you do?”. Least privilege is about keeping the second answer as narrow as possible. A strong password or MFA protects the door; it says nothing about how many rooms are behind it.

It is not a reason to slow everyone down. “Just make everyone an admin” removes friction today and turns every account into a full-access target tomorrow. The cost of least privilege is mostly paid once, in careful role design. The cost of skipping it is paid during an incident.