Credential Sharing as a Service: The Hidden Risk of Low-Code/No-Code

According to the "2022 Verizon Data Breach Investigations Report," stolen credentials were the top path leading to data breaches. More often than phishing or exploiting vulnerabilities, attackers gain direct access to credentials, letting them virtually walk into victim organizations using the front door.

Low-code/no-code platforms make it extremely easy for users to share their credentials and embed their credentials into applications, thus drastically increasing the risk that employee mistakes will result in credentials leakage. Unintentionally, low-code/no-code development makes the No. 1 resource for attackers easier to obtain.

How Low-Code/No-Code Platforms Sacrifice Security For Productivity

Getting the required permissions to do your job in an enterprise can be very frustrating. It's not uncommon for new employees to wait more than a month before they have the full scope of permissions they need to access business data, review KPI dashboards, or join an internal communication channel.

The same thing is true, maybe even worse, for setting up a new application in the enterprise. Permissions requests typically need to be approved by your direct manager, their manager, and the team who owns the data/service. Some of the approvers might be in another continent with a time zone difference. It's next to impossible to start building an application without the required access to data/services, and so you end up waiting.

After you manage to get the right access for your application, you are finally ready to start building. A few months go by. Suddenly, you get a notification that your application has failed. A quick analysis shows that its permissions have been revoked. Enterprises typically set up an automated process that revokes access every few months, unless permissions are explicitly asked for by the application maker. This process is necessary to comply with regulations and reduce over-permissions, but it has its downsides — namely a periodic manual process that could hinder productivity.

Low-code/no-code is an attempt to empower every employee, especially business professionals, to address their own issues with custom-built applications and automations. Vendors do this by systematically identifying and removing roadblocks for building applications. Is learning to code challenging or scary? A drag-and-drop interface can help lower the barrier to entry. Is integration difficult? A wide range of managed connectors will remove the need to know what an application programming interface (API) is or how to interact with it. Is asking for permissions slowing you down? Sharing identities and leveraging existing user access can provide a quick alternative.

To boost innovation, low-code/no-code platforms allow their users to leverage their existing user identity, embed it within an application, and by doing so circumvent the enterprise permissions model entirely. For an outside viewer in security or IT, the application doesn't exist, and everyone using it is actually running it on its maker's account.

Wait, But How?

If you're thinking that there are better solutions out there than letting the application impersonate its maker, you are partially right.

In recent years, OAuth has been the de-facto standard for granting application access. Any time you go to a software-as-a-service (SaaS) marketplace, pick up a third-party integration, and get prompted with a small login and consent pop-up, you're most likely using OAuth. OAuth has many different consent flows, all resulting in the familiar pop-up experience. A key distinction is whether consent is granted to the application directly or on behalf of its currently signed-in user. Although this might sound like a minor detail, it is actually the root cause of the low-code/no-code identity problem.

When an application is granted consent directly, it is issued its own identity, separate from that of the user who granted the consent. The application identity can be monitored for suspicious authentication or access patterns, and its permissions can be revoked at any time by a security or IT admin. Controls like IP restriction can be put in place to take advantage of the static nature of the infrastructure that the application runs on. Every application can have a separate identity, with separate access restrictions, and can be monitored and acted up--on separately. Another useful implication of application identity is admin control.

Granting consent on behalf of the currently signed-in application user, however, has very different implications. The application gains access to resources using its user's identity for the limited time when the user uses the app. On-behalf access means that the application is actually using its user's identity directly when querying external resources. Moreover, using multiple applications will result in all of them using the same identity: the user's identity. IT or security admins looking at logs will not be able to easily distinguish between the user or any application used by the user. Granting application access on behalf of users was originally designed to allow temporary access only while a user is actively using the application.

In many cases, services allow applications to gain access on behalf of users but deny applications direct access to service APIs. This raises an interesting question: If an application can only gain access to data on behalf of a user, how can it access data when no user is interacting with it? Creative engineers have come up with a solution. The application logs in as a user once, then records its authentication token and keeps on using it even after the user has logged off the application. In the case of low-code/no-code applications, that user is typically the application's creator. User authentication tokens are supposed to be short-lived in order to prevent this workaround. In practice, however, most services issue tokens that are valid for 12 months.

Let's say a business professional creates an application. Instead of having to wait for approval of an application identity or permissions, they use access on behalf of a user — in this case, their own. The application requires them to log in once (say to Salesforce or SharePoint), records their own private authentication token, and reuses it at will. Even if another user is using the application, it will still use its maker's identity.

There are ways to build low-code/no-code applications with dedicated identities — for example, by using service accounts. However, the methods are not very widely used.

Recall the positive properties of application identity stated above: The application can be monitored, its access to data can be controlled, and its privileges can be revoked. None of this is true when low-code/no-code platforms are embedded with their creator's identity. Every application a business professional makes might have their user identity built into it. Security and IT teams analyzing access logs will have no way to know that these applications even exist.

Impersonation-as-a-Service

Recording and replaying user authentication tokens as a way to grant applications access to resources has another implication: They open the door to simple and easy identity sharing among users. This manifests in a common low-code/no-code feature typically referred to as connections. Connections are how low-code/no-code applications gain access to resources like Slack, NetSuite, or BambooHR. They allow read operations, like reading employee HR data; write operations, like the ERP on recent sales; and delete operations, like permanently deleting a Slack channel. Connections are first-class objects, which means they can be created by one user and shared with another user, an entire team, or even an entire organization. Technically speaking, these are wrappers around user authentication tokens or hard-coded credentials.

When a user creates and shares a connection to Microsoft Office, for example, it is akin to them sharing their password. However, if a team of developers is collaborating on a project, they often need to be able to share an application identity with each other. Connection sharing enables working together in a team on a shared project, but unfortunately it can also enable users to share their identities with each other. Since many low-code/no-code applications are built with the creator's identity embedded within, identity sharing is a common risk low-code/no-code platforms introduce.

To make matters worse, credential sharing is just way too easy on many platforms. A single checkbox stands between you and sharing your identity — for example, your ServiceNow or Salesforce account — with your entire organization. In some cases, sharing an application with other users implicitly shares its underlying connections too.

This is a crucial point. Under certain circumstances, users who gain access to a business application will gain direct access to its underlying database implicitly, without direct consent or knowledge. Take an expense management application, for example. There's a big difference between letting people use the application to submit their expense reports and giving them access to the underlying database with everyone's expense reports within it.

Unintentionally, low-code/no-code applications make credentials — the No. 1 resource that attackers are after — easier to obtain.

Where Do We Go From Here?

As we've seen, low-code/no-code platforms had to overcome many challenges in making enterprise applications easy to build for everyone from professional to business developers. Sometimes, the solutions come at a cost. In the case of credentials, the ability to move fast is unfortunately coupled with the ability to break things — namely, the enterprise identity model.

It is important to mention here the immense value that low-code/no-code platforms create for the enterprise: reducing the time between idea and execution, lowering the bar for application development, and increasing business velocity.

Platforms cannot be expected to resolve security concerns on their own; it is a responsibility shared between the platform and its customers. To reduce the risk, security teams should familiarize themselves with the ways identities are treated as part of the low-code/no-code platforms their organizations use. Most platforms can be configured to reduce the level of credential sharing and turn off implicit sharing.

More importantly, security teams must realize that low-code/no-code platforms introduce an inherent new risk into the enterprise that cannot be mitigated by traditional monitoring approaches because of the confusion between application and user identities. Therefore, security teams should invest in guiding business developers, reviewing potentially risky applications, and taking action to mitigate risk.