Low and No Code can cause massive Authorization Misuse
Learn what are the issues behind and how you can prevent this!
Sharing connections in between departments can be a powerful mechanism for collaboration, but it also poses significant security risks, when co-workers can access data via APIs in Low and No Code applications. Just imagine you have access to the Outlook or Gmail of a Co-Worker in your low and no code tool.
Thats why you should always use so called service connections, these should be the first-class objects in modern no-code/low-code platforms. This means connections between applications, other users, or entire organizations have been authorized based on client secret and client token, they are usually not binded to one specific user. Well anyway these applications can also be shared with users who should not have access to their underlying data. For example, if an application connects to a customer data store like a Salesforce CRM, then another user may be able to view customer data without any authentication checks being performed.
No-code/low-code applications aren’t built in silos. Their impact is based on integrations across the organization’s stack. Most platforms come built-in with a large set of connectors (APIs), which allow quick and easy connectivity. This means that connections can be shared among applications, with other users, or with entire organizations.
Most of the times you cannot limit the API scope even though it is today more important then ever, as Patrik Simek noted.
You think this security risk in iPaaS won’t happen?
A citizen led developer creates a connection to their company e-mail account. They inadvertently click on the “share with everyone” option. Every person withinside the organization of the low and no code tool, which includes contractors and vendors, gains access to their company e-mail account. A malicious coperate-user triggers a “forgot password” form and makes use of the connection to get the reset URL via with the low and no code system and can overtake the account. Was pretty easy right?
To see records from a database, a creator writes a straightforward application. The application is set up such that each user can only view records that are relevant to them. The program is set up, though, so that the user is implicitly given access to the connection to the underlying database. A user of the program can connect directly to the database and have complete access to all records. You think this is out of this world? Check our GIF where we access a coaching group via this kind of access-level in slack.
Admin uses a service account to connect an application to their source code management system (i.e., GitHub). For easy integration, the supplied service account has full access to all repositories. Any internal user can take use of this link to gain access to restricted repositories that they ordinarily wouldn’t have. You just lost all your Code.
Risk in Low and No Code Automations iPaaS?
Many no-code/low-code platforms take advantage of OAuth permission procedures by querying, saving, and reusing user refresh tokens at will in order to boost productivity and speed up delivery. Because connections are linked with user identities that are challenging to track or deny, business users can easily set them up without worrying about secrets or permissions. OAuth refresh tokens are intended to be temporary, yet they typically last for a few months or even years. As a result, a link made by a business user in less than a minute could remain in the no-code/low-code platform for a long time and frequently be utilized by other users for purposes other than those for which it was originally intended.
What can you do to prevent this?
- Disable or monitor the use of implicitly shared connections. This can be achieved by setting up clear rights and roles, enabling teams and don’t cross-share one login like we have seen oftentimes in Zapier, Make.com, and Other iPaaS tools.
- Minimize the API Scope as Patrik Simek described so as adhere to the principle of least privilege when providing access to SaaS tools that can contain shared connections or access to multiple channels.
- Monitor no-code/low-code platforms for over-shared connections this is probably the most challenging part of managing the IT landscape of the future, I can recommend for Make and N8N, Wemakefuture to set up a custom API listener/prevention tracker, NCScale to scrape the blueprint and Switchboard to understand how everything is connected. This helps to provision and decline access for secure corporate governance.
- Educate business users on the risks of connection sharing and its relation to credential sharing. Is by far the best solution and use Teams to prevent inter-department-sharing.
