In this article, we'll provide a brief introduction to low-code development and the different tools and platforms available for low-code development. After discussing the trends, growth, and a few downsides of low-code platforms, we'll focus on the article's main agenda. With security concerns being the most cited issue amongst developers and critics of low-code, we'll focus on the security vulnerabilities that could occur, how to test them, and how to deal with them.
What Are Low-Code Development Platforms?
Low-code development platforms (LCDPs) offer a drag-and-drop or WYSIWYG interface that enables users to write code, rather than a conventional text editor or IDE where the developer must write all the code from scratch. A few examples of low-code development platforms are Appian, Mendix, Tidelift, Salesforce, and Crowdbotics. Low-code apps are becoming increasingly popular; Forrester predicts the total LCDP market to reach 21 billion USD by 2022.
A low-code development environment is not an entirely new concept. For years, design engineers have been using rapid prototyping for 3D printing, CASE (Computer-Aided Software Engineering), and CAD (Computer-Aided Design) software for building products.
LCDPs mimic the same concept as CAD, using a graphical user interface to build programs and abstract the process of hand-writing codes. Many developers and enterprises are beginning to embrace LCDPs because of the benefits they offer. Here are some major advantages of LCDPs:
- Developers don't need to be proficient with any particular coding language. Understanding the tools and requirements of the LCDP itself will suffice.
- This, in turn, makes it easy for managers to bring on new talent, as LCDPs reduce the onboarding learning process significantly.
- Development time is faster, providing more time to concentrate on the application's more subtle or customized details.
- The resulting applications are more user-friendly and scalable than traditional, manually coded apps.
However, there are a few downsides to LCDPs. For instance, LCDPs can sometimes limit developer creativity by offering fewer customization options. You don't know the underlying software and the logic used to run your application, leaving a knowledge void there. LCDPs are not often built to support many third-party integrations, either.
However, let's go ahead and address the most severe concern that teams voice about using LCDPs: security.
Security Concerns in Low-Code Development Platforms and How to Tackle Them
Here we'll see what kind of security issues low-code platforms pose, how developers can identify these loose ends, and how to deal with them.
Vulnerabilities Via Third-Party Integrations
If an organization is new to the low-code ecosystem, the developer team tends to follow handwritten coding norms. One standard routine followed is using third-party integrations. These external integrations could be with cloud services, applications, or databases.
Integrations could be added for numerous reasons such as search, captcha, shopping cart, login and authentication, emails, messages, and so forth. As discussed earlier, low-code platforms may not natively support the incorporation of such integrations. Hence, they don't handle any security threats that arise due to such integrations, which are unfortunately a common risk.
Integration-related vulnerabilities could also arise when we try to deploy our application outside of the low-code platform. For this reason, it is best to deploy in the same environment as the LCDP.
What can you do about it?
Developers should avoid using any unsupported integrations for any feature or functionality in the LCDP. The team should receive enough training to get accustomed to the low-code environment. An outside chunk of code could expose the application's sensitive data, leading to a data breach and other security attacks.
You should build the required functionalities using the low-code platform rather than by using a third-party integration. In most cases, you can achieve this by building your own APIs within the platform. LCDPs Are Seen As Black Boxes of Code
Most organizations and developers perceive the low-code environment as a black box where the underlying working is hidden. This is true to a large extent because most of the backend activities in the low-code environment are not visible to the developer. This raises concerns about a few possible security vulnerabilities:
- Since low-code deployment happens with a click of a button, APIs are generated automatically. These APIs may reference your data models and other such operations where the business logic applied in these tasks is unknown to the developers.
- Most companies fear that since they don't have direct governance and control over low-code platforms, their data and customers' sensitive data might be at risk.
- Most low-code vendors and their solutions do not undergo publicly reviewable security audits; this could leave the platform's security vulnerabilities unaddressed.
How can you test for these vulnerabilities and tackle them?
- The most important thing is to make an informed decision while choosing your LCDP based on your requirements. Here's an article to help you with that.
- As discussed in the previous section, LCDP vendors don't provide you with admin access to their overall platform. As a result, you'll need to make use of third-party auditing services to keep your security in check.
- You can request legal agreements like security and compliance certifications, service level agreements, and cybersecurity insurance, which would address their security concerns to a greater extent.
- There are testing tools available to detect security vulnerabilities in web application platforms. Since manual testing and debugging is not feasible, automated tools are of great help. Here are a few of them:
- OWASP ZAP: Developed by OWASP (Open Web Application Security Project), ZAP (Zed Attack Proxy) is a cross-platform, open-source platform security testing tool. ZAP is one of the most successful projects of OWASP. It is used to find several security vulnerabilities in a web app during the development and testing phases. It could be used by a professional with a lot of experience and entry-level learners as well.
Its test coverage includes: intercepting proxy server, traditional and AJAXWeb crawlers, automated scanner, passive scanner, forced browsing, fuzzer, WebSocket support, scripting languages, and plug-n-hack support. - W3af: One of the most popular security testing frameworks developed using Python is W3af. The tool allows testers to find over 200 types of security issues in web applications, including blind SQL injection, buffer overflow, cross-site scripting, CSRF, and insecure DAV configurations.
- SonarQube: SonarQube is an open-source testing tool capable of code analysis and checking security vulnerabilities. Written in Java, SonarQube can analyze over 20 programming languages for vulnerabilities. Furthermore, it gets easily integrated with continuous integration tools like Jenkins. Some of the vulnerabilities exposed by SonarQube include cross-site scripting, Denial of Service (DoS) attacks, HTTP response splitting, memory corruption, and SQL injection.
Check for Cloud Infrastructure Security and Open-Source Vulnerabilities
After checking our platform and code concerns, let's jump into infrastructure vulnerabilities: specifically, cloud services and open-source platforms. Not all LCDPs are commercial or subscription-based; there are many open-source platforms as well.
Open source low-code platforms might rely on many dependencies and third-party integrations. Even if our source code doesn't pose any security threats, the dependencies and integrations could create a great deal of risk exposure. Hence, it's imperative to keep the application secure from such attacks. Tools like WhiteSource Bolt could be helpful.
Most LCDPs have built-in deployment to public cloud services. But some platforms allow the developer to choose their cloud service. Private clouds are not much of a problem, but it's essential to keep security in mind when using a public cloud.
Most of the public cloud services include tools to verify the infrastructure for security. For instance, when the APIs are deployed, the application is tested for security issues in other environments first and then pushed into production. Also, tools such as InSpec provide compliance-as-code to ensure that the intent of the provisioned infrastructure is always being met. Generally speaking, you need to be sure that your cloud instance has some monitoring going on.
There are other tools that continuously run in the background, checking for security attacks. On more open LCDPs, this can be done using CI/CD pipeline tools, which offer continuous protection against malware. Jenkins is a popular open-source CI/CD choice amongst developers. These tools can provide added layers of protection while meeting the organization's application development demands.
Low-code platforms are a treat if used the right way!
Low-code platforms are a boon to developers and organizations. However, there are various pitfalls to be wary of, the greatest of which is security. As we've show, any LCDP's security questions can be easily answered with some knowledge and practice. There's a reason LCDPs are popular; the increased speed of development, no strict technical requirements, and easy deployment more than justify the cost of some up-front vetting.