Reduce overprivileged permissions and apps

As a developer aiming to design and implement applications that follow the guiding principles of Zero Trust, you want to increase application security with least privilege. It's imperative that you reduce the attack surface of your application and the effect of a security breach.

In this article, you learn why applications shouldn't request more permissions than they need. You understand the term overprivileged and discover recommendations and best practices for limiting privilege in your applications to manage access and improve security.

What is overprivileged?

Overprivileged occurs when an application requests or receives more permissions than it needs for it to properly function. Improve your understanding of overprivileged with examples of unused and reducible permissions in the remainder of this article.

Unused permissions

For this unused key example, imagine that there are three locked doors (blue, yellow, and green) as shown in the following diagram.

Your assets are behind the doors. You have three keys (blue, yellow, and green) that allow you to open its corresponding door. For example, the blue key can open the blue door. When you only need access to the yellow door, you only carry the yellow key.

To best protect your assets, you only carry the keys you need when you need them and keep unused keys in a safe location.

Reducible permissions

The reducible keys example is more complicated than the unused key example to which we now add two special keys as shown in the following diagram.

The first black key is a pass key that can open all the doors. The second black key can open the yellow and the green doors. When you only need access to the yellow and the green doors, you only carry the second black key. You keep your pass key in a safe location with the redundant green key.

In the Microsoft identity world, the keys are access permissions. Your resources and you, the key holder, are applications. If you understand the risk of carrying unnecessary keys, you're aware of the risk of your applications having unnecessary permissions.

Permission gap and risk

How can doors and keys help to understand how overprivileged occurs? Why might your application have the right permissions to perform a task, but still be overprivileged? Let's look at the permission gap that might cause the discrepancy in the following diagram.

The X axis represents Time and the Y axis represents Permissions. At the start of the measured Time, you request and receive permission for your application. As the business grows and changes over time, you add new permissions to support your needs and the slope of Granted Permissions increases. The Permissions Used might be lower than Granted Permissions when you forget to remove unnecessary permissions (for example, if the application doesn't break) resulting in a Permission Gap.

Here are interesting observations in the Microsoft identity platform.

• We have more than 4,000 APIs in Microsoft Graph.
• More than 200 Microsoft Graph permissions are available on Microsoft identity platform.
• Developers have access to a wide range of data and the ability to apply granularity to the permissions that their apps request.
• In our investigations, we found that apps have only 10% fully utilized permissions for their scenarios.

Think carefully about what permissions your app actually requires. Beware of the permission gap and regularly check your application permissions.

Security compromised for overprivileged

Let's dive deeper into the risks that result from permission gaps with an example. This compromising scenario comprises two roles: IT admin and developer.

• IT admin: Jeff is a tenant admin who ensures that applications in Microsoft Entra ID are trustworthy and secure. Part of Jeff's job is to grant consent to permissions that app developers require.
• Developer: Kelly is an app developer who uses Microsoft identity platform and owns apps. Kelly's job is to ensure that applications have the right permissions to perform required tasks.

The following common security compromise scenario for overprivileged typically has four stages.

1. First, the developer starts configuring the application and adding required permissions.
2. Second, the IT admin reviews required permissions and grants consent.
3. Third, the bad actor starts cracking user credentials and successfully hacks the user identity.
4. If the user owns multiple applications, they're also overprivileged. The bad actor can quickly use the token of the granted permission to retrieve sensitive data.

Overprivileged applications

An entity is overprivileged when it asks for or receives more permissions than it needs. The definition of overprivileged application in Microsoft identity platform is, "any application with unused or reducible permissions."

Let's use Microsoft Graph as part of the Microsoft identity platform in a real-world example to better understand unused permission and reducible permission.

Unused permission occurs when your application receives permissions that aren't necessary for the desired tasks. For example, you're building a calendar app. Your calendar app requests and receives Files.ReadWrite.All permission. Your app doesn't integrate with any files' APIs. Therefore, your application has an unused Files.ReadWrite.All permission.

Reducible permission is more difficult to discover. It occurs when your application receives few permissions but has a lower privileged alternative that would provide sufficient access for required tasks. In the calendar app example, your app requests and receives Files.ReadWrite.All permission. However, it only needs to read files from the signed-in user's OneDrive and never needs to create new files or modify existing ones. In this case, your application only partially utilizes Files.ReadWrite.All so you need to downgrade to Files.Read.All.

Recommendations for reducing overprivileged scenarios

Security is a journey, not a destination. There are three distinct phases in the security lifecycle:

• Prevention
• Auditing
• Remediation

The following diagram illustrates recommendations for reducing overprivileged scenarios.

• Prevent: When building an application, you should fully understand the permission required for the API calls that your application needs to make, and only request what's necessary to enable your scenario. Microsoft Graph documentation has clear references for least privilege permissions to most privileged permission for all endpoints. Be mindful of overprivileged scenarios as you determine which permissions you need.
• Audit: You and IT admins should regularly review existing applications' previously granted privileges.
• Remediate: If you or IT admins notice an overprivileged application in the ecosystem, you should stop requesting tokens for the overprivileged permission. IT admins should revoke granted consents. This step usually requires a code change.

Best practices for maintaining least privilege permission

Two major incentives for maintaining least privilege permission with your applications are driving application adoption and stopping the spread.

• Drive adoption by building a trustworthy app for customers that avoids excessive permission requests. Limit your application permissions to only what it needs to complete its task. This practice reduces the potential blast radius of attacks and increases customer adoption of your apps. Apply more scrutiny when reviewing permissions that applications request and deciding whether to grant app permissions.
• Stop the spread by ensuring attackers are unable to use excessive privileges to gain further access. When you create an app that asks for unnecessary permissions, it's least likely to receive approval or denied altogether. The best way to control damage is to prevent attackers from gaining elevated privilege that increases the scope of the compromise. For example, if your application only has User.ReadBasic.All to read user basic information, then your OneDrive, Outlook, Teams, and any confidential data are safe if an app is compromised.

Next steps

• Acquire authorization to access resources helps you to understand how to best ensure Zero Trust when acquiring resource access permissions for your application.
• Building apps with a Zero Trust approach to identity provides an overview of permissions and access best practices.
• Customize tokens describes the information that you can receive in Microsoft Entra tokens. It explains how to customize tokens to improve flexibility and control while increasing application zero trust security with least privilege.
• Configure group claims and app roles in tokens shows you how to configure your apps with app role definitions and assign security groups to app roles. These methods help to improve flexibility and control while increasing application zero trust security with least privilege.
• Achieving Zero Trust readiness in your apps: Designing for Least Privilege helps you to design apps using the principle of least privileged access with the Microsoft identity platform.
• Increase application security with the principle of least privilege helps you to reduce the attack surface of an application and the effect of a security breach (the blast radius) should one occur in a Microsoft identity platform-integrated application.
• Graph Explorer and Microsoft Graph permissions reference helps you to select Microsoft Graph API calls to enable your app scenario and find corresponding permissions from least to most privileged.