More organizations than ever are adopting and employing low-code and no-code application development approaches. This is largely due to the simplicity and ease of deployment involved, as well as efficiency in creating applications quickly. With this agility and simplicity, however, come a wide variety of potential security risks that could lead to data exposure, system and/or account compromise, and other significant security issues.
To mitigate the challenges of low-code/no-code app development and prevent risks from occurring in the first place, follow these key best practices.
Choose the right service provider
A primary concern is the security of the operating environment where the applications are developed and potentially run. Organizations should employ no-code and low-code service providers that offer security controls and assurances within their environment. Some providers offer controls that customers can employ, such as data encryption, identity federation and logging, while others offer little or no security.
Limit and secure credentials
Low-code/no-code approaches are prone to credential misuse and privilege exploitation, especially if code is associated with a developer account that has extensive privileges in the development environment or with connections to databases and other components.
Mitigate these risks by ensuring security and identity teams are involved in the application design process wherever possible. Monitor low-code/no-code platforms and any connections for excessive or illicit privilege use. Connection logs to other systems and databases can help identify these in many cases. Where possible, implement lower-privilege accounts and connections.
Prevent data exposure and leakage
Another concern with low-code/no-code apps is data exposure and data leakage arising from improper data handling methods and poor application logic that interacts with data stores.
Since most data providers don’t offer explicit security controls, such as encryption or data masking, to their customers, it is important to limit public exposure of low-code/no-code apps wherever possible. Position the apps behind a security brokering system, such as a content delivery network (CDN) or cloud access security broker, that offers data monitoring and protection controls in transit.
If monitoring is available for the low-code/no-code platform, security and operations teams should enable it to monitor for possible data flows and connections.
Perform application security testing and ask for SBOMs
One of the biggest areas of risk with low-code/no-code application and development environments is the code itself, as well as the components, back-end packages and functions used in development.
In traditional development environments, organizations that place emphasis on security run security tests against coding and packages applications — using static application security testing (SAST) and dynamic application security testing (DAST) tools, respectively.
These tools aren’t always readily available for low-code/no-code development and deployments. The best organizations can do is request SAST and DAST results on their back-end components and code used in deployments. This may or may not prove successful.
Another tactic growing in popularity is requesting — or even requiring — a software bill of materials (SBOM), which lists all the code and packages used in the provider environment, as well as some attestation of continued threat monitoring and vulnerability management. Like SAST and DAST results, this may not always be successful.
Improve visibility
Many security teams feel they have little to no visibility into low-code/no-code apps and environments. Organizations ideally won’t employ platforms that offer no logging or monitoring at all. At a minimum, organizations should enable user access logs and platform audit logs if available or implement a brokered access strategy through CDNs that support logging and monitoring for all access to applications and/or platform providers, which are primarily SaaS.
Educate employees
In addition to mitigation tactics, it’s worth mentioning that security education for anyone developing using low-code/no-code tools is paramount. Given the relatively sparse availability of built-in security controls and capabilities within these provider environments, it’s incumbent on everyone to understand the potential risks and work to reduce or avoid them if possible.
