Security risks of low-code/no-code development platforms

The low-code/no-code development market is growing at an astounding pace. However, low-code does not necessarily mean low risk. Below, we explore the security risks of low-code and no-code development platforms. 

What are “low-code/No-code development platforms”?

Low-code/No-code development platforms enable organisations to build applications with little to no hand-coded programming. Instead, users create applications with visual drag and drop components that sit within an intuitive, user-friendly graphical interface. Low-code/no-code is particularly popular in small and medium-sized businesses, with Accenture research indicating that half of SMBs have deployed these applications. 

While the terms low-code and no-code are often used interchangeably, there are differences between the two. It’s important to note that ‘no-code’ platforms do not actually exist. No-code platforms essentially refer to instances where all code is hidden from the creator, giving the appearance of no code at all. By contrast, low-code platforms offer hand-coding functionality blended with visual components for a faster application development cycle.  

The lack of coding in low-code and no-code applications enable companies to accelerate deployment while empowering non-technical employees to rapidly build applications. Well-known examples of these applications include Air Table, Microsoft Power Platform, Google App Maker, Zoho Creator and Fliplet. 

The low-code/no-code market is growing rapidly. Forrester predicts it will reach $31 billion in spending this year, while Gartner forecasts that these platforms will account for 65% of all app development by 2024.  

However, organisations must realise that low and no code doesn’t equate to low or no risk. Below, we’ll explore the security implications surrounding low-code/no-code development platforms and offer guidance on how your company can engage with these platforms securely.  

Why are low-code applications vulnerable to security incidents?

Low-code applications are not inherently more secure than those built using traditional coding methods. Low-code platform vendors are responsible for securing the underlying infrastructure of these applications and tend to ‘bake in’ some key aspects of security, which can mitigate common application security risks. However, it is up to the organisation to use the application to ensure that secure configurations and controls are in place.  

Moreover, if developers start customising these applications or tweaking the generated code, they risk introducing business logic flaws. As well as this, we must remember that low-code applications rarely exist in isolation. They are often deployed on private hosting sites or connected to external services which may, themselves, suffer from security vulnerabilities.  

Furthermore, low-code platforms have led to the democratisation of application development. We are seeing more and more ‘citizen developers’ – employees who don’t have a technical background that create applications using low-code – who may not have the proper levels of training to build secure applications – or may not prioritise secure development.  

Lastly, low-code or not, all technology platforms are vulnerable to security weaknesses. With low-code platforms, there is concern that organisations misguidedly believe that all security management is in the hands of the platform vendor. This simply isn’t the case. Without proper testing and secure development, these platforms are as vulnerable to security incidents as hand-coded platforms.  

The top low-code/no-code security risks

 The privacy and security concerns around low-code/no-code applications are mounting. Recently, OWASP released a new document on the top 10 low-code/no-code security risks. The document is currently a work in progress, and the final three risks are yet to be established.  

Here is an overview of the major risks identified so far:  

1. Privilege abuse/escalation: Low-code applications tend to use identities provided by the application creator as opposed to service identities. This means end-users have control over who has access to the applications they create. A threat actor could easily access unauthorised resources and manipulate the application environment if user credentials fall into the wrong hands.  
2. Data leakage: Low-code applications are primarily used for automating business tasks – many of which involve transferring data. Unless the application process is carefully constructed and reviewed, low-code applications can create instances of shadow IT, whereby data is moved outside of the organisation’s traditional boundary to unknown applications and devices that the IT team does not know about.  
3. Insecure authentication: Low-code applications are not created in isolation. They connect to other enterprise applications, resources and data. However, citizen developers rarely have the authentication expertise to ensure that connections to data sources are secure. For example, connections may use HTTP instead of HTTPs or use weak encryption ciphers.  
4. Application misconfigurations: One of the greatest strengths of low-code platforms is the ability they give employees to create customised, tailored applications at speed. Speed and flexibility can come at a cost, though. It is easy for users, for example, to unintentionally configure applications so that they are publicly available, which puts sensitive data at risk. As an example, Microsoft Power Apps recently made the headlines after a misconfiguration meant that 38 million data records were configured to allow public access. 
5. Dependency injection: Low-code applications depend on a marketplace ecosystem of components and connectors that users can deploy to build their applications. These may include third-party integrations for search, captcha, shopping cart, messages, and so forth. In many cases, users can implement components from any source, which could lead to the unintentional deployment of fraudulent components, designed by threat actors. If these malicious components are embedded into the application, threat actors can manipulate the application and its data. This threat is somewhat similar to the threat of downloading fraudulent applications from a mobile application store.  
6. Oversharing: Low-code applications are built for collaboration. It’s extremely straightforward and intuitive for users to share components and data. On the flip side of this, users may unwittingly share resources with the wrong recipient or too many recipients, which can undermine security.  
7. App impersonation: Just as threat actors often impersonate reputable companies like Salesforce and Microsoft for phishing, they may also fraudulently pose as a legitimate low-code application provider. Such phishing scams can be used to steal sensitive information or even to launch malware on the victim’s device.   

How to mitigate low-code/no-code security risks

 To defend against the security risks associated with low-code/no-code applications, organisations should approach application development with the same security principles as they do hand-coded applications. This means secure development practices and incorporating regular security testing.  

The security of these applications is a shared security model: the vendor takes responsibility for application and infrastructure security. The customer is responsible for securely configuring the application to meet their own standards, managing identity and access control, and handling authorisation.  

Given this, the low-code/no-code vendor is responsible for application penetration testing to ensure their application and the hosting infrastructure are secure. As a customer, there are still assessments that a testing provider can run for you to ensure you have securely configured the application and to see if they can access your apps or restricted parts of them. These typically take the form of a secure configuration review during which the tester identifies opportunities to ‘harden’ the application. 

Whilst these security configuration reviews are not web application penetration tests in the classical sense, they are still critical security assurance exercises that can identify weaknesses and improve the security posture of your low-code tools.  

As well as incorporating these security measures, we also advise that y assess the vendor’s security management practices to minimise the risks of supply chain security incidents.  

Moreover, if you rely heavily on citizen development within your company, you should look to train your employees on secure application development principles to reduce the likelihood of vulnerabilities being introduced during the development phase.  

Need Help?

If your organisation needs help running a penetration test on an application or infrastructure, we’re here to help. We can assess your environment and run a full penetration test. We can also advise you on any follow-up actions or remediations from our findings.