Privilege - Less is More
In The Battle Between Security And Convenience, Security Always Wins
“Least Privilege” is a guiding security principle of systems and solutions. While there are different ways to word it precisely, the idea is the same:
"Do not allow or release any more than absolutely necessary."
It’s a simple principle, but without keeping careful watch, you might find convenience popping up as a good reason to not worry about it.
The Why
Security
Security is at the heart of Least Privilege - never leave a solution with a gap that could be exploited by someone with malicious intent. Consider application service accounts: Applications use them to connect to resources as part of normal operations. Since you can never know which accounts might be compromised beforehand, you need to treat them all as though they could be. You mitigate risk by granting a given service account only with the permissions it needs to function. An account like this should never use a super-user account by root access - this is the worst type of access an attacker could have.
This is also true of end user interactions and APIs. For example:
A login screen should not inform the user if the entered username is invalid
A password reset endpoint does not need to reveal if the user entered an already-registered email
A proxy should not unnecessarily reveal hostnames of back-end servers.
URLs and cookie names should not noticeably reference the applications to which they belong.
Each of these endpoints would provide information to a potential attacker, helping them to identify the product (and perhaps a vulnerability) or lend credence to a phishing attempt. For some of these situations, maybe the business wants to make it easier for the end-user. For others, maybe it is a deadline, a knowledge gap or a product limitation that provides an opening. You don’t want that risk in your system, and if you phrase it to the business in the right way, neither would they.
Development
Granting only Least Privilege is not just for production - good security practices during development turn into good practices in subsequent environments. Start by granting only the privileges you need and, if is not enough, add to it as little as possible. This will ease migration to your new environments, as not only will you know what your application needs, you know how to make it happen. You will not be hampered later by difficult-to-diagnose errors - possibly caused by using a super-user account in Development, but getting a read-only account in Stage.
Damage to your systems may always not be malicious. An inappropriately scoped account could ruin a system during development or migration because of a code error. A script to clear out a directory might speed up development; however, if left in by accident, could have devastating effects on Production. Sticking to Least Privilege could save a system that may take significant time to rebuild if something goes awry.
The Take-Away
Cutting corners is convenient and there will always be a deadline to meet or a case where it “just isn’t worth it.” Good practices in production come from practicing security earlier on. Do not release unneeded information. Do not allow unneeded permissions. It could mean the difference between a secure system and one with the door blown wide open.