Beyond the Hype: The Truth About Low-Code and No-Code Platforms

In the last few years, the rise of low-code/no-code platforms has democratized mobile app development and made it more accessible to the masses. It eliminated or minimized the arduous process of learning to code, which, frankly put, is not everyone's cup of tea. Even Apple came up with its app builder that lets you create iOS apps for any Apple devices, without writing a line of code. 

As we all know by now, low code/no code platforms are tools that allow anyone to create mobile or web apps with minimal to no coding. “Anyone can build an application,” that's the mantra these platforms go by.      

Users can build apps by dragging and dropping the application components and connecting them together, thus creating an app or software.

For the business side, these platforms have made it cheaper to develop an application or software, allowing them to be more cost-effective as we all know that hiring a developer in the US is expensive.

Organizations nowadays have immense pressure to deliver applications faster. This also contributed to the popularity of low-code/no-code tools as it removed the complexity that goes into building an application or software. 

But it's not all sunshine and rainbows, as these tools are not without problems. There is no code ownership, the security is inadequate, and these platforms are limited by scalability. Also, there are security and privacy risks related to applications developed on these tools (more on this in a minute). 

The intent is to present an honest critique of no-code/low-code platforms. I will talk about the drawbacks of these platforms and how their limitations can impact application development. Also, I will cover security and privacy risks related to applications developed on these tools. 

Let’s start with the drawbacks first. 

We will go through each of them in detail one by one. 

Poor Flexibility and Customization Options

Low-code or no-code platforms are too rigid and restrictive for complex use cases. As they are meant for non-technical users, it is easy to create a simple application or a workflow with these platforms. But this simplicity and ease of use come at the cost of customization and flexibility that some people may want. 

Take, for example, the technical details that go into application development. Low-code/no-code platforms completely eliminate all of them. For instance, features like optimizing the code, configuring the server, or designing the database that are fundamental to application development are missing. In fact, you will completely lose control over the technical aspects of your application.

Also, these platforms are built on specific programming languages or frameworks that may have their own set of limitations. They might not work for certain use cases or may require extensive customization depending on the requirements.   

That’s not all! There are other limitations, too, like you cannot build a custom user interface in low-code/no-code platforms without the platform provider’s support. Implementing advanced features like animations or complex layouts in these tools will also be difficult.

You will face roadblocks in integrating your application with a custom or proprietary system. 

All of the above will require traditional coding to implement. Lastly, there is no scope for complex business rules or custom logic.   

Limitations like these contribute to the lack of flexibility and customization in low-code/no-code platforms. 

Lack of Control Over the Underlying Code and Infrastructure

You can optimize or customize your application to your heart's content when you build it from scratch. But the same cannot be said when you create one through low-code/no-code platforms.

That's because the entire infrastructure and code are managed by the platform provider, which means the only changes you'll be able to make will be on the 'drag and drop' level and not on a deeper, more critical level.They will limit you with their pre-built templates, components, and modules that come with the package.  

Due to this lack of control, these tools are not suitable for projects that require complex functionalities or need to meet strict security or compliance standards. You are better off with traditional coding if you want to build an application that requires complicated algorithms, advanced data analytics, or even machine learning and artificial intelligence.  

Also, as the platform providers control everything, you won't be able to integrate your application with legacy systems or complex back-end infrastructure without their support. 

Too Much Dependency on Platform Providers for Support and Update

You are entrusting everything to platform providers when you decide to build an application in a low-code/no-code platform. That means you will always be at their mercy in case there are any problems with the platform itself. Any updates to features and functionalities for your application have to be provided by the platform providers. 

Also, it’s not possible to extend the functionality of low-code/no-code platforms without the resources and tools of third-party vendors. 

That’s not all! What if the platform provider decided to discontinue their services one day? What if they experience technical issues with their services? Your application will hit a rough patch in such situations, and you won’t be able to do anything about it. 

A similar incident happened in 2019 when Google decided to shut down its low-code platform App maker service. The sudden discontinuation of their services caused panic among users who were using the platform for their application. Many had built entire businesses with the help of this tool.

Worrying questions arose in their mind such as: Should they rebuild everything from scratch? Or find a new platform to work with in the future? 

The lesson startups, a group that may be most tempted to rely on such platforms, can take from this incident is that it’s risky to rely on third-party platforms for support and updates, especially when they can pack it up anytime on their whim. 

Limited Integration Capabilities With External Tools and Technologies

Low-code/No-code platforms can integrate with some third-party tools like Google Drive, Salesforce, and Dropbox. But, these pre-built integrations are limited in their functionality and may not be enough for most users. For example, they may only support a subset of features in the third-party tool and might be incompatible with a specific data format or communication protocol that the user may need. 

This will be a problem if someone has complex integration requirements because they will be forced to resort to custom coding to get the desired results. The entire process will be time-consuming and require advanced technical knowledge.    

Also, these low-code/no-code platforms may straight out not integrate with custom-built or an older legacy system that is not supported by their pre-configured integrations. 

There are also limitations in terms of the types of integrations that can be configured. Some no-code/low-code platforms may only support simple data transfers between systems and may not be able to handle real-time integrations or sophisticated data conversions. This can be an issue for organizations that need to integrate with multiple systems or require real-time data synchronization.   

Unable to Optimize Performance and User Experience 

As these platforms provide pre-built components and templates, the code it generates might be bloated and unoptimized. This may slow your application’s load times, negatively impacting its performance and delivering a poor user experience.  

Also, the pre-built UI components and the limited set of features and functionalities can put a dent in providing an engaging and user-friendly application that truly fulfills customer needs. So, once again, designing the application might become easier, but it may come at the cost of user experience and performance.

Despite these drawbacks, more businesses will inevitably adopt low-code/no-code platforms in the future as this technology evolves.

This entire industry will be worth $36.43 billion by 2027. But the point I am drawing home is that it's essential to raise awareness about the issues surrounding these tools so that people can set realistic expectations for them. 

Next, I will be sharing some stories that highlight the security and privacy risks related to applications developed on these tools. 

User Impersonation in Low-Code/No-Code Apps

The story shared here is from DarkReading and is based on a real-life scenario from a multinational B2C company. This short summary will give you an idea about the entire situation. You can check out the link to learn everything about the incident.   

Jane was a customer care representative for a large organization. As part of profile she and her peers  had to look into customer cases, but then they faced issues  as key information about their customers, like their latest purchase or support case history was missing. She observed that this often irritated the customer as they would have to explain their issues multiple times until it got routed to the right person who could resolve the issue. 

To solve this problem, Jane created an app through low-code/no-code platforms that will allow company employees to get all the essential information about the customers when they are assigned to resolve their issues. 

Jane experienced multiple issues when trying to build the application. The biggest one was permissions. Employees across the company didn't have direct access to the customer database for the information they needed. To resolve this issue, Jane logged into the database and embedded her authenticated session directly in the application. 

So, when the application receives a request from one company user, it will use Jane's identity to execute that query and return the results to the user. This credential embedding is a key feature of low-code/no-code platforms.  

But soon, there was a problem. The application had implicitly shared Jane's authenticated database session with other customer care representatives in the company. By sharing the app with a user, they got direct access to the connection, which was essentially just a wrapper around an authenticated database session provided by the low-code/no-code platform. 

Through this connection, users could leverage the authenticated session directly. They no longer had to go through the app. It was soon revealed that several users had found this out and, thinking that this was the intended behavior, started using Jane's authenticated database session to run their queries. They liked this solution since using the connection directly gave them full access to the full customer database, not just for customer cases they were assigned to but the entire data.

The connection was soon deleted, and the incident was resolved. The company reached out to users who had used Jane's connection to ensure they discarded any customer data they had stored.

This is a perfect example that demonstrates how a person unknowingly shared their user identity with other users without knowing it in the first place.

Let me explain in technical terms what just happened. 

User identities are embedded within the application, and as multiple people use the application, it creates a direct path to privilege escalation, where they gain access to levels they should not have access to in the first place. 

Applications built on no-code/low-code platforms can take advantage of embedded user accounts instead of having their own identity. Embedded identities can belong to the one who created the application, or they could be a common identity shared by teams, like database credentials. It could also be service accounts or shared identities. 

This lack of application identity hides its existence from monitoring systems outside the no-code/low-code platform. So, any user that uses the application is impersonating the person that created the app, and there is no way to differentiate between the application and its creator.   

The issue becomes even worse when applications use different identities to operate on various platforms, or when it misconfigures private data as public, which I will explain in the next section.

Security Misconfiguration 

No-code/low-code platforms provide a comprehensive list of features. Some of which maintain the delicate balance between security and support of specific use cases. For example, misconfigurations may occur if someone anonymously accesses sensitive data or operations and unprotected public endpoints. This happens because many settings are set on the application level instead of the tenant level, meaning they can be set by business users rather than administrators. 

One such incident was when the default permissions on Microsoft Power Apps exposed 38 million data records. I will give a short summary of the entire incident. 

Microsoft Power Apps are low-code tools to build apps and create private and public websites. This application’s portal was configured to allow public access, which down the line, became the ultimate reason behind the data leak. 

Upguard discovered the issue involving ODdata API that powered the portal and revealed that the core issue is that all data types are considered public when some of them should have been private, like personal identifying information. This private data got leaked due to misconfiguration. 

American Airlines, Microsoft, J.B. Hunt, and the governments of Indiana, Marylands, and New York City were impacted by the leak. 

IT and cybersecurity personnels worry over the lack of oversight regarding how applications built with these tools access and use enterprise data. Here are some interesting stats that elaborates this further.  

These stats show that security personnels find it hard to trust the security of these app-building platforms and don’t even know how to check for vulnerabilities in low-code/no-code applications. 

There is a lack of clarity regarding the breach in security that can appear at any time. 

All of this is a major drawback for a technology that is increasingly becoming popular and useful for app development.  

Parting Thoughts

The purpose of this blog was not to bash these platforms, and the points I raised were not made in ill faith. I acknowledge that the ability to build something with minimal to no coding is a boon for many non-technical users. 

There is no doubt that these tools are very convenient for quickly building simple applications or workflows. 

Similarly, you can use these tools for creating simple apps that let you manage projects, events, and inventories or for tracking your personal finances and organizing your travel plans.  

So if you want to use these no-code/low-code platforms for building simple apps and workflows, then go for it; they are excellent. 

But, if you want to build an application with complex functionalities, or prefer extensive customizations, then it’s best to build one with traditional coding. 

Low-code/no-code platforms will severely limit you with their pre-built templates and components, and the code they generate might be unoptimized, which may negatively impact your application’s performance.  

Without the support of low-code/no-code platform providers, you will face difficulties in integrating your application with legacy systems or back-end infrastructure. They will control the entire code and infrastructure and can shut down at any time, leaving you hanging. 

In terms of security, low-code/no-code applications are susceptible to privilege escalation, where a person can gain access to data they should not have access to in the first place. There are high chances of misconfiguration where private data can be identified as public, thus making it more vulnerable to leaks. 

Ultimately, it all comes down to your requirements and use cases. So keep that and above points in mind when deciding the right approach for building your application.