There’s no denying that low-code is a rising trend in application development that’s likely to stay for the long run. Its impressive benefits in terms of agility and development time are convincing the enterprise, so it’s no wonder that the industry is on its course to achieve fivefold growth between 2017 and 2022.
In low-code platforms, building custom cloud applications can be achieved by reusing components through a simple drag-and-drop interface, which means reduced engineering efforts. Then, APIs can be used to hook components together and maximize compatibility.
Although many steps of the way can be achieved without actively writing a single line of code, many low-code apps include advanced logic written in JavaScript. So, when it comes to understanding the threat model of low-code platforms, we must consider security considerations that arise from using JavaScript code.
Low-Code and JavaScript
Because JavaScript needs to be interpreted by a browser to work, it is exposed and anyone can access, read and modify it. This becomes problematic because companies store important business logic on the client-side, which is often unavoidable due to the inexistence of a back end or the need to avoid performance losses. So, companies’ proprietary algorithms and logic end up running on an adversarial environment, which opens the door to a series of attacks—namely, automated abuse, piracy, intellectual property theft and data exfiltration.
When it comes to protecting code, typically we’re led to the concept of encryption. However, JavaScript encryption is not a feasible strategy; the browser always needs to interpret JavaScript so that it works. If we have a decryption key, we need to supply it to the browser; if that key becomes compromised, all the code will be easily accessed.
A suitable approach to protect JavaScript is transforming it into a new version that is extremely difficult to understand while also preventing attackers from debugging or tampering with the code.
When it comes to enterprise or commercial applications, JavaScript must be protected with maximum resilience—that the protected code will prevent attackers from using automated tools against it. On top of this, the code should contain runtime defenses that break the application whenever attackers try to debug or tamper with the app’s source code.
Conclusion
Low-code still means a lot of code. Even though most of it will not appear on the front stage, development teams must not forget that it should always be protected. Attackers love low-hanging fruit and unprotected source code of enterprise apps is certainly a low-effort, high-gain venture.