Low-code and no-code app security

Low code, no code and zero code are buzzwords in the world of business apps in which tasks that once required programmers are done by ordinary users. The required functionality is assembled from ready-made templates, the interface is drawn in a WYSIWYG editor as necessary, and the program logic is described by way of simple diagrams or very short code snippets. All this can be handled by a competent PC user with no special training. Low code helps cut development time for a simple mobile app from six months to a couple of weeks, while a promo page for an online store or a new report can be delivered in a couple of hours.

There are plenty of no-code platforms out there: Bubble for developing mobile apps, Webflow for designing websites, and Parabola and Airtable for analytics and data science. All of these systems help companies reduce IT costs and speed up the development of business functions.

Sure, there are pitfalls – with cyber-risks being chief among them. To keep a company’s data and processes secure, these risks need to be minimized as early as during implementation of the low-code platform. Here’s what should be kept in mind the most.

Privileged accounts

A mini-app developed by your company on a low-code or no-code platform often needs access to various databases and computing resources. It usually runs with the privileges of its creator, and all subsequent users of the app perform actions with this level of access. From there it’s a short hop to privilege-escalation attacks, and figuring out from the logs who’s responsible for malicious activity will be problematic.

Risk mitigation

• Implement the principle of least privilege for all database and API connections from the no-code system.
• Use separate accounts for mini-app users (using the credentials of the app developer is unacceptable).
• Introduce special logging measures for tracking who actually uses the mini-apps when they query databases and APIs.

Incorrect authorization

Almost all low-code platforms use the connector/connection concept, allowing them to access databases and other applications within the company. The architecture of these systems gives a user no direct control over a connection after they grant permission to establish it. The connection can be reused to make other requests for the same data – including from a different mini-app or even a different user.

Risk mitigation

• Frequently refresh authorization tokens in systems linked to the no-code platform.
• Monitor actively used connections.
• Rewrite incorrectly programmed mini-apps that use “borrowed” connections. Disable unnecessary connections.
• Again, use the principle of least privilege.
• Train business users to understand the risks of overly wide access to app data.

Data leakage or modification

With the no-code platforms having wide access to data, mini-apps programmed by non-specialists can return more data than the developer intended. And errors in data processing or synchronization between systems can lead to unintentional, widespread data corruption or unauthorized copying.

Risk mitigation

• Restrict access to data, minimizing write and delete permissions.
• Minimize the list of employees authorized to create and modify connections, and configure access rules for them.
• Monitor data transferred by the no-code platform to identify excessive amounts thereof in a timely manner.

Incorrect security settings

Dangerous bugs and misconfigurations can occur in mini-app code, such as: access to file storage without encryption; storage of API keys or other secrets right in the code of the app; access to corporate systems without proper authentication. Since many low-code apps are easy to analyze, attackers can quickly exfiltrate all this information and use it for cyberattacks and further data theft.

Risk mitigation

• Ensure compliance with industry best practices for configuring apps and keeping secrets.
• Train business users who build no-code apps to adhere to these practices.
• Introduce additional security measures at the infrastructure level. Restrict insecure access methods, and monitor anomalous requests from no-code systems.

Poor input sanitization

Most low-code apps have some kind of interface that allows you to input data; for example – contact details in a form on the newly built website. Verification of input forms is often insufficient or non-existent, leaving them open to classic SQL injection attacks.

Risk mitigation

• Train business users: the mini-apps they create must verify and sanitize any incoming information, be it a text form, CSV file or anything else.
• Deploy additional data sanitization tools – for example when passing SQL queries from the low-code platform to a database.

Vulnerabilities in modules

Many no-code platforms have modular architecture with their own component stores for user projects. Vulnerabilities in these components are often very serious and made worse by the fact that they cannot be traced and quickly updated using standard tools. Such modules can even be trojanized if their developer gets hacked.

Risk mitigation

• Regularly clean the platform. Unused plug-ins, modules and other components must be removed.
• Limit the list of components available to users.
• Inventorize all components in use, and monitor vulnerabilities and releases of new versions.
• Use protection systems specifically designed for your low-code platform (for example, Wordfence for WordPress).

Illegal data processing

Databases stored by mini-apps are sometimes subject to the general rules of a particular low-code platform, meaning that company administrators don’t have full control over their location and content. This may lead to violations of local laws, such as GDPR, regarding storage of certain types of data.

Risk mitigation

• Train business users in the basic rules of data processing.
• All apps that potentially have access to sensitive data must be checked by the infosec team.

Forgotten apps

By their very nature, no-code apps are easy to create and easy to leave running unnoticed. For example, if an employee leaves a company, their mini-app may continue to run and create daily reports. Or a colleague may carry on using it unbeknown to the IT and infosec teams.

Risk mitigation

• Maintain a detailed catalog of mini-apps, their owners and end users.
• Delete unnecessary apps and connections. Check allowlists of users and remove any who no longer need the app.