Low-code and no-code app builders can hinder companies and Decrease Security

Low-code and no-code app builders can hinder companies in the long run with technical debt and security risk. These app builders allow less skilled people to build out business applications. I’m going to tackle this from both technical debt added to the company, and the lack of security understanding leading to increased risk.

Ease of use adds to Quantity

When using app builders, less skilled individuals are able to create front-end applications without needing to learn about the computer science behind what they’re doing. This allows individuals to quickly develop front-end applications for their organization. With this ease, individuals could be enticed to create more applications, as the time to develop it is minimal.

Platform lock-in

When using app builders, your company is locking into a platform. Unlike programming an app using Java, Objective-C, Kotlin, or Swift; there’s no way to move your app to a different platform. If your organization wishes to move to a different platform, not only is there no way to transfer to a different platform, but some app builders lock your organization into the back-end as well. If the company that made the app builder ceases development, or collapses, you’re also stuck, and your back-end could be lost.

Lack of understanding

Individuals creating these apps don’t have an understanding of what’s going on. They don’t understand why performance issues happen if they arise, and because the code is a black box, others can’t assist. The connections that an app makes is also an unknown, especially for those that are run on a server not maintained by the organization. Dependencies are also an unknown, your organization won’t know if the app is running on unsupported libraries, so the longevity could come into question.

Longevity

The two paragraphs above talk about platform lock-in and the unknown back-end dependencies. Those two things along can bring into question the longevity of an app. This may still be true, to some point, with apps developed by the organization; however, when the application is written by the organization, this can be remediated at the pace of the organization. When your organization is locked into a platform, this must be done at the pace of that platform.

Take for example an app developed with back-end support for an Excel document. Your app can utilize the data in an Excel document; however, the maintainer of the library chooses to not support a library that the app relies on. If your organization developed the app, you can choose to keep the dependency versions in lock-step until the data has been migrated to a supported back-end. However, if you choose to use an app builder, this must be done when the platform owner chooses to update their libraries.

Increased risk

There’s a lot of unknowns when it comes down to using app builders. As mentioned above, you may not know what protocols and dependencies the app utilizes. While the app may have a secure front-end, it may still utilize an unencrypted back-end. If the app utilizes a database connection, the platform owner may choose to not encrypt the communications to the database. Or the platform owner may choose to utilize FTP instead of SFTP/SCP for file transfers for legacy or speed reasons.

You may not have any choice, or knowledge, of library dependencies that the platform owner chooses to use. They may choose to utilize legacy libraries that have known security vulnerabilities because it would take a lot of work to migrate to the new version. Platform owners may also choose to not utilize libraries with new features that you may wish to use.

Handing app development over to individuals that are less technical, and less experienced, could lead to increased risk of data exposure. Inexperienced individuals may not understand how to properly secure data, or what data can be exposed to others. This isn’t a technical issue, this is an information security issue, and that comes with experience. For example, not exposing production data in a development environment. For example, not properly restricting access control so that only HR can see their data.