the principle of least privilege

When a guest stays in your home for one night, you do not hand them the keys to every room, the safe, and the car. You give them just what the visit requires: the front door and the spare bedroom. If they turn out to be careless or dishonest, the damage they can do is bounded by what little you gave them. That instinct — give each actor only the access it genuinely needs, and nothing more — is the principle of least privilege, one of the oldest and most important ideas in computer security.

Stated precisely: every subject (a user, a process, a piece of code) should run with the minimum set of privileges required to do its legitimate job, for the minimum time. A web server that only ever serves files needs no power to install software or read other users' mail, so it should not have it. The practical payoff is in what happens when something goes wrong. If that web server has a bug and an attacker hijacks it, the attacker inherits exactly the server's privileges — so the smaller those privileges, the smaller the blast radius. Least privilege turns a potential catastrophe into a contained incident.

Applying it shapes real design: long-running daemons drop from administrator down to an unprivileged account as soon as they have done the one privileged thing they needed (like binding a low port); programs are split so that only a tiny, carefully reviewed piece runs with high privilege; capabilities and fine-grained permissions replace coarse all-or-nothing power. The honest caveat is that least privilege is easy to state and hard to do well — figuring out the truly minimal set of rights is tedious, and the lazy path of just granting broad access is always tempting, which is exactly why so many breaches trace back to over-privileged code.