Principle of Least Privilege

In Turkish: En Az Ayrıcalık İlkesi

Updated September 30, 20263 min read

In short

The principle of least privilege is a security rule that every user, program, and service gets only the minimum access it needs to do its job, and no more.

What is the principle of least privilege?

The principle of least privilege, often shortened to PoLP, says that each account, process, or system should have exactly the permissions its task requires and nothing beyond that. A reporting service that only reads orders should not be able to delete them, and a developer who works on one project should not have administrator access to every production server. The idea dates back to computer security research in the 1970s and is now a foundation of modern security design.

In practice it means granting narrow, specific permissions instead of broad ones: a database user with only SELECT on the tables it needs, a cloud role that can read one storage bucket, an API token scoped to a single repository. It also covers time, since temporary, just-in-time access for rare admin tasks is safer than permanent rights, and unused permissions should be reviewed and removed regularly. Programs themselves should run as unprivileged users, not as root or administrator, and containers should drop the capabilities they don't need.

The main benefit is limiting the blast radius. If an attacker steals a least-privilege credential or exploits a bug in a service, they can only do what that identity was allowed to do, so a stolen read-only reporting token can't be used to wipe the database. Think of a hotel key card: it opens your own room and the gym, not every room in the building, and it stops working when you check out.

Least privilege is often confused with RBAC and zero trust. RBAC is a mechanism for assigning permissions through roles, and a role that grants too much still breaks least privilege, while zero trust is a broader architecture that verifies every request and treats least privilege as one of its core rules. In short, least privilege is the goal, and access control systems are the tools used to reach it.

Key takeaways

Grant each user, service, and process only the permissions its task requires.
Prefer narrow, scoped, and temporary access over broad, permanent rights.
Run programs as unprivileged users rather than root or administrator.
Least privilege limits the damage when an account or service is compromised.
Review and remove unused permissions regularly, since access tends to accumulate.

Example

Giving each service only the database access it needssql

-- A reporting service only needs to read two tables
CREATE ROLE reporting_service LOGIN;  -- password set from a secrets manager
GRANT SELECT ON orders, customers TO reporting_service;

-- So it cannot change or delete anything:
-- UPDATE orders SET total = 0;  -- ERROR: permission denied for table orders

-- The checkout service can read and add orders, but not delete them
CREATE ROLE checkout_service LOGIN;
GRANT SELECT, INSERT ON orders TO checkout_service;

Readers ask

What is an example of the principle of least privilege?

A web app that connects to its database with an account that can only read and write its own tables, instead of a superuser account. If the app is hacked, the attacker cannot drop other databases or create new admin users.

What is the difference between least privilege and zero trust?

Least privilege is a rule about how much access to grant. Zero trust is a wider security model that assumes no network or device is automatically trusted and verifies every request, with least privilege as one of its core principles.

What is privilege creep?

Privilege creep is the gradual buildup of access rights, for example when people change teams but keep their old permissions. Regular access reviews and expiring permissions prevent it.