Principle of Least Privilege

The Principle of Least Privilege means that every user, service account, API key, and process in your application should have only the minimum permissions necessary to perform its intended function, and nothing more. A customer support agent does not need access to delete database records. Your application's API should not connect to the database with admin-level credentials. A microservice that sends emails has no business reading payment records. In practice, this is implemented through role-based access control (RBAC), where users are assigned roles like "viewer," "editor," or "admin," and each role has a tightly scoped set of permissions. It extends to infrastructure as well: database users with read-only access for reporting queries, API keys with limited scopes, and cloud service roles that can only access specific resources.

Why It Matters

Least privilege is your containment strategy. When a breach occurs, and eventually one will, the damage is limited by the permissions of the compromised account. If an attacker gains access through a junior employee's phished credentials, least privilege means they can only see what that employee could see, not the entire system. If a single microservice is exploited, the attacker can only reach the resources that service had access to, not your entire infrastructure. Without least privilege, every compromise becomes a total compromise. The principle also protects against insider threats and honest mistakes: an employee cannot accidentally delete production data if their role does not have delete permissions. For multi-tenant applications where different customers share the same infrastructure, least privilege ensures that one tenant's data is never accessible to another.

What Happens Without It

The 2020 SolarWinds supply chain attack demonstrated what happens when least privilege is not enforced. After compromising the Orion software update, attackers gained access to networks at 18,000 organizations including multiple US government agencies. In many of these environments, the Orion monitoring tool had been granted broad administrative access across the entire network, far more than it needed to function. This excessive privilege allowed the attackers to move laterally through systems, access email servers, steal sensitive documents, and maintain persistent access for months without detection. Organizations that had properly scoped Orion's network access to only what it needed for monitoring were significantly less impacted. The breach, which affected the Treasury Department, Commerce Department, and major technology companies, became a textbook case for why every component in your stack should operate with the absolute minimum permissions required.