Low Code and No Code: The Security Challenge

This is an article from DZone's 2022 Low Code and No Code Trend Report.

For more:

Read the Report

Many companies are looking to low-code and no-code platforms to build apps in the visual environment. They provide the opportunity for faster app development and reduce the dependence on highly skilled developers. Companies may hire less experienced or only minimally trained staff (I’ll call them citizen developers) to meet service gaps and to respond to skills shortages, ensuring their larger dev team can focus on more advanced projects. 

Poorly chosen low-code and no-code platforms and poorly managed projects and teams can bring with them a number of security vulnerabilities that, if not addressed, leave companies (and potentially their customers) in a world of pain. Let’s take a look at some of the key challenges and risks and how they can be avoided.

Common Low- and No-Code Security Challenges

Shadow It

Low-code and no-code tasks expand the developer pool. This can make it hard for team leaders to keep track of what is being built and with what resources. Inexperienced or citizen developers may be using insecure software or practices without the knowledge of the security or IT team. For example, a lack of knowledge of authentication may lead to the use of HTTP instead of HTTPs. Risks also include storing data insecurely, like on a personal device instead of within the company-vetted cloud. 

Business Continuity, Resiliency, and Ownership Failures

Low-code and no-code applications may be poorly tracked, updated, and even overlooked in efforts like business continuity planning. They may be perceived as low-priority and left without ownership if staff members leave or if the citizen developers go back to their original tasks. As there is a lack of standards across platforms, it may be harder to replace developers with specific knowledge. More chaotic companies may not even know how many of such apps are live, much less continuously monitor them for security vulnerabilities.

While developers and developer marketing media may perceive low-code and no-code providers as the next big thing, business owners and decision-makers may not be familiar with them or consider such services to not be suited to "real-world" applications. 

Lack of Transparency

Low-code apps may be made from proprietary software using a proprietary language, frameworks, and libraries. This may make it harder to see what’s under the hood in the first place. There’s a lack of awareness as to what software is behind the platform, what versions it runs, and potential vulnerabilities they may introduce to your application. This lack of transparency can make it hard to move between platforms and providers, keeping companies locked into a particular provider with no simple way to migrate. 

Third-Party Vulnerabilities

Unsurprisingly, low-code and no-code apps limit their focus to their own product and thus, focus their security parameters on their own products. If developers try to customize the app outside of its native low-code platform — by integrating it with cloud services, other applications, or external databases — it may result in security challenges. For example, a citizen developer may unwittingly connect to a fake app that closely replicates the real version, potentially resulting in a dependency injection or data theft. 

Privilege Escalation

Apps made in low-code applications may feature the default personal user credentials written by the original developer. This means that app access may include access to the underlying credentials and thus access to unauthorized resources or the ability to elevate your own privilege. 

Lack of Auditing of Vendors

Security risks escalate if a citizen developer doesn’t know how to screen third-party vendors for security risks — especially as even the most well-respected vendors may come with security vulnerabilities. For example, in 2021, UpGuard security researchers found the default settings for Microsoft’s PowerApps portals were configured to “expose records for display” — unless deliberately modified by third-party users. (This was stipulated in the accompanying documentation, which shows you should always read the documentation!) 

As a result, 38 million online records were exposed — many with personally identifiable information (PII) such as Social Security numbers. To their credit, Microsoft issued a software fix. If such an event had occurred with a more obscure software company, it may not have been picked up, or even resolved. The choice of vendor matters. 

Poor User Account Permissions

The bigger the team, the more tempting it may be to skip good practices in onboarding. According to Meredith Bell, chief executive officer at AutoRABIT, cloning Salesforce permissions can lead to a world of security vulnerabilities. 

He notes that large organizations often clone the permissions of active users when creating new Salesforce user accounts. “This means a small change in the permissions of a single user could unintentionally proliferate across the organization, enabling unauthorized users to expose data (intentionally or not).” 

How to Respond to Low-Code and No-Code Security Challenges 

Fortunately, there are plenty of ways to secure low-code and no-code apps. Let’s take a look at a few ideas: 

Train All Team Members in Security Best Practices

If you employ citizen devs, ensure they receive ongoing and security training for working on low- or no-code projects. 

Monitor User Permissions

When assigning user capabilities, whenever possible, use secure-by-default settings and allow role-based access control (granting access only to those that need it). Embrace a zero-trust security model where access is granted on a least-privilege basis. 

Keep an Inventory of Your Apps and Software

Make sure you keep track of your team’s use of low-code and no-code platforms, as well as the applications they create. You should know where all sensitive data lives, especially if it's created using low-code and no-code platforms. 

Maintain Compliance and Governance

All code should be subject to the same protocols, using universal practices such as built-in permissions and established safeguards like code reviews and maintenance. Protocols should always adhere to industry standards and regulations such as HIPAA, ISO, and GDPR. 

Verify Vendors, Their Apps, and Tools

When choosing low-code and no-code platforms, there are a number of key questions to consider: 

• Can the vendor supply a software bill of materials?
• What data governance policies does the company hold?
• Do their security policies protect direct access to underlying data services?
• Does the platform have a robust user interface to allow testing of libraries and APIs?
• Where are their platforms hosted?
• Does the software have security compliance checks built-in, such as PCI (for payment), HIPAA (healthcare), and FedRAMP (government), or comply with industry standards or ISOs relevant to your sector?  

Third-Party Security Auditing

There are a number of automated testing tools which can find vulnerabilities in development and testing. These include: 

• Source code security analyzers: The National Institute of Standards and Technology (NIST) has a handy list of tools.
• Static analysis tools like SonarQube enable devs to discover security issues early, often in real-time as they write code. The tools scan as the dev writes, then flag any security issues in the engineer's integrated development environment (IDE) or editor.
• Runtime environment testing can reveal data disparities in security controls to avoid situations such as posting sensitive data to a public location.
• Also helpful are W3af and Open Web Application Security Project (OWASP)’s Zed Attack Proxy for finding web application vulnerabilities.
• In general, it's always important to secure the API layer through building in secure practices such as secret keys, digital signatures, or OAuth. The API can be tested for vulnerabilities or bugs using an API scanner. OWASP has a good list of API security tools.

Conclusion

Low-code and no-code developer tools are ever-growing in popularity as a way to increase productivity and accelerate innovation. But for them to achieve their desired aims, good security practices must be embedded throughout the development process and within the tools used. Otherwise, the efficiency is replaced with a whole lot of security headaches.

This is an article from DZone's 2022 Low Code and No Code Trend Report.

For more:

Read the Report