Low-code/no-code security risks climb as tools gain traction

What are low-code and no-code?

Low-code and no-code are rapid application development models that enable users to apply visual methods, such as drag-and-drop and interactive menus, to automate how they generate code. With low-code, users can add custom code alongside auto-generated code from the platform. With no-code options, only the platform's auto-generated code is ultimately included in the ensuing application.

Common use cases exist for each approach:

• No-code is usually reserved for simple UIs, dashboards, and basic web and mobile applications, among others.
• Low-code, since it is customizable, can be used in a broader variety of application scenarios.

In no-code, all code is generated through drag-and-drop and via menus. Low-code usually offers API and integrated development environment (IDE) support, code templates and a variety of plugins that can be used with other tools and services.

What are the security risks of low-code and no-code?

Regardless of the approach, a number of low-code/no-code security risks and potential vulnerabilities and exposures can occur. The major issues include the following.

Quality of code

Among the top low-code/no-code security risks is the quality of the code itself. Both approaches include some code generated entirely within the context of a third-party platform. These code snippets can vary widely in quality depending on the tools and services employed. Plus, there may be little to no oversight or scrutiny on whether the code conforms to known security best practices.

Monitoring

Low-code approaches almost always rely on development teams using tools -- IDEs at a minimum -- that can be monitored by security teams. Performing full static analysis or dynamic testing of code may not be possible, however, at least for the code generated by the platform.

That's not the case with no-code. In these situations, there may be little or no monitoring of code development and deployment. This can lead to new forms of shadow IT that could be difficult to detect, resulting in an overall lack of visibility for security teams.

Third-party security issues

Organizations that use a third-party environment to build and host the application code introduce a shared responsibility model for security. The organization's network could be vulnerable if the provider does not have adequate or capable security controls in place to protect the applications developed.

Traditional application issues

In addition to risks inherent in the creation and hosting of no-code and low-code apps, these platforms are still subject to all the same major application flaws and vulnerabilities we've noted for years. This includes SQL injection, cross-site scripting, command injection, and authentication and authorization flaws.

Many traditional testing tools and methods -- both static and dynamic -- don't easily integrate with low-code and no-code approaches, if at all. And, because low-code and no-code make it easier for someone with little or no background to create code, the likelihood that bugs and security issues are introduced can go up significantly. The security community has been working for many years to help educate development teams on best practices to develop and test secure applications, particularly for those engineered to handle sensitive data.

Overall, both coding approaches offer a lot of promise, but low-code/no-code security risks exist. These risks are further elevated when companies -- lacking adequate monitoring and testing capabilities -- give users with no coding knowledge or development oversight the ability to create applications.