The Principle of Least Privilege (POLP) has been around for some time — the term appears in the Department of Defense’s Computer System Evaluation Criteria, published in 1985. And Michael Gegick and Sean Barnum wrote about Least Privilege for the US government’s Cybersecurity and Infrastructure Security Agency (CISA) back in 2005.

In cybersecurity, Least Privilege is a digital cousin of the idea of operating on a “need to know” basis. It’s recommended for several reasons:

• Improved system stability: The fewer privileges a piece of code or an app has, the less likely it will be to perform actions that can interfere with other apps or the machine.
• Easier deployment: When an application doesn’t require much access to a system, it can be deployed without the need for additional steps like installations or passwords.
• Better system security: The less access to a system a program has, the less likely its vulnerabilities can be used to exploit a system or machine.

The idea of Least Privilege takes on a new level of importance when it comes to APIs because there are more sources of data and more developers in play. While tools like the OpenAPI Specification are helpful for standardization, they don’t really help when it comes to assigning appropriate permissions and privileges.

Below we’ll look at why Least Privilege is important to APIs and consider how this rule can be approached in the context of APIs.

Least Privilege and APIs

In computing, privilege typically refers to whether or not an app, user, or piece of code can perform security-relevant functions. It’s a fairly generic term, but its most obvious association with the API space is probably permissions.

API consumers should be granted permissions for actions they’re authorized to carry out. In cases where those permissions need to be expanded, they should be revoked afterward. In simple terms, don’t expose any more information than you need to. This is particularly important in the API space because it’s not just your customer data that’s at risk, but potentially data from other sources as well.

A CyberNews report, for example, found that some third-party apps connected to cryptocurrency exchanges via API keys left some users vulnerable to fraudulent withdrawal attempts even when withdrawal permissions were disabled by default on those cryptocurrency exchanges. It would appear that trade permissions weren’t disabled by default, and, as a result, hackers were able to use API keys to trade away balances in unprofitable trades to accounts that they had set up. This is just one case of many where granting fewer privileges would have avoided exploits.

How To Implement Least Privilege?

Effective API security consists of many different measures, and POLP is just one concept in that toolbox. It’s worth pointing out, however, that many of the API security best practices listed below actually fit pretty well under the umbrella of POLP:

• Remove unnecessary API users.
• Shrink your attack surface by scoping API users.*
• Disable obsolete APIs through versioning and remove deprecated features.
• Use Two-Factor Authentication (2FA) and OAuth 2.0 for access control.
• Apply rate limiting to reduce the risk of brute force attacks.

*When connecting with other pieces of software, it’s always a smart idea to set proper access levels and grant different permissions for different tasks like Xero does:

“Apps using the API have the permissions of a Standard or Adviser level user. To access reporting APIs the authorizing user must have Reports access and for Payroll APIs the authorizing user must be a payroll admin.”

Talking about authorization issues, Hakluke and Farah Hawa wrote the following for Detectify:

“Authorization issues are typically difficult to detect in an automated fashion. The structure of the codebase should be set up in a way that it is difficult to make authorization errors on specific endpoints. To achieve this, authorization measures should be implemented as far up the stack as possible. Potentially at a class level, or using middleware.”

We’ve also previously written about RBAC privilege escalation and why automating POLP is tricky in this scenario, namely that “traditional security scanning solutions can’t catch these issues, since they take the form of completely legitimate API requests.”

The solution? “To conduct a continuous assessment of all API endpoints and how they map to various roles.” And while that might sound arduous, it’s a lot less arduous than dealing with the fallout from a full-blown API data breach…

The Dangers of Privilege Creep

It isn’t surprising that privilege creep, or entitlement creep, is a risk in the API space — most API developers want to make their platforms as open as they can to expose helpful features and reduce friction during adoption.

Waiting around for manual approval of an API key, for example, is enough to make some API consumers look for a solution elsewhere. Privileges and permissions, however, are one of the areas in which erring on the side of caution is a good idea. Furthermore, regularly reviewing access permissions doesn’t only aid security, but is becoming increasingly essential to ensure compliance with SOX, HIPAA, GDPR, and other regulatory requirements.

With tools designed to detect permission creep in file system access controls already in existence, it’s likely that we’ll see attempts to track, monitor, and fix dangerous changes to privileges and permissions within the API space in years to come. Given the relative difficulty of doing so, time will tell how effective those attempts will be.