OWASP Low-Code Top 10 – What the Security Recommendations Mean for A12 Applications

While low-code approaches are becoming increasingly popular, security aspects are also drawing more attention. The OWASP Low Code/No-Code Top 10 was recently published as a list of the most common security risks that organizations should be aware of when developing and deploying low-code applications. We summarize to what extent the points affect A12 applications.

When it comes to software security, the Open Worldwide Application Security Project (OWASP) is one of the most important institutions. Security experts around the world volunteer their time to contribute to a growing community. The non-profit organization promotes the development of security technology and makes numerous tools and resources freely available.

With the OWASP Low-Code/No-Code Top 10, a key document for low-code applications is now in the starting blocks. The documentation project is currently in “Lab” status. It has thus already passed the “incubator” phase and reached a certain degree of maturity, but is still in the development phase and does not have the same commitment as the established projects.

The ten OWASP risks in detail – and how A12 is doing

In the following, we summarize what needs to be considered with regard to the listed risks for applications based on the Enterprise Low Code Platform A12:

1. Account Impersonation (LCNC-SEC-01)
   Point 1 describes risks that arise from embedded developer accounts. However, there are no such accounts in A12. Instead, A12 has its own authentication and authorization model. Accordingly, A12 applications are not affected by this scenario.
2. Authorization Misuse (LCNC-SEC-02)
   See point 4.
   
3. Data Leakage and Unexpected Consequences (LCNC-SEC-03)
   See point 4.
4. Authentication and Secure Communication Failures (LCNC-SEC-04)
   Points 2 to 4 are closely related to connectors that establish connections to other external systems. Here, misuse of authorizations, data leaks or breakdowns in authentication and secure communication can occur with many low-code platforms. In A12, such connectors are not part of the direct modeling scope. There are pre-built adapters to common external systems. However, they are used exclusively by the development team according to individual needs and are specifically secured.
5. Security Misconfiguration (LCNC-SEC-05)
   Point 5 summarizes anonymous access to sensitive data, unprotected public endpoints, and problems related to multitenant applications under the overall category of “misconfiguration”. In A12, we follow the concept of “Security by Default”. This means that all deployed modules are configured securely in the standard. In the documentation, we draw particular attention to configurations that have an impact on the security of the application and that must be taken into account in individual solutions.
6. Injection Handling Failures (LCNC-SEC-06)
   Point 6 addresses risks from malicious code injection via user-supplied data – a threat that potentially affects all web applications. To validate user input, A12 uses rigorous validation on both the client and server side. If the application also allows input from other sources, project-specific security precautions must be taken.
7. Vulnerable and Untrusted Components (LCNC-SEC-07)
   Point 7 covers all risks caused by the use of vulnerable and untrusted components. In A12 development, we have implemented processes to regularly check all our dependencies for known vulnerabilities. As part of the build pipeline, our homegrown tool ATLAS performs various security scans. Potential vulnerabilities of the A12 platform and of applications based on standard A12 components are thus detected very early.
8. Data and Secret Handling Failures (LCNC-SEC-08)
   Point 8 involves problems with storing confidential data when it is stored on the shared databases and systems of low-code providers. A12 applications are usually set up to have completely dedicated resources for databases, secrets and logs. Therefore, all sensitive data remains in the hands of the application operator.
9. Asset Management Failures (LCNC-SEC-09)
   Point 9 describes the risk arising from applications that are no longer used and were created by individual users. However, since A12 is used exclusively for the development of business applications as part of professional software projects with larger teams, this case does not occur in practice.
10. Security Logging and Monitoring Failures (LCNC-SEC-10)
    Point 10 describes shortcomings in logging and monitoring. Two different types of monitoring are relevant here: On the one hand, monitoring traffic is basically essential for all web applications – and thus also for A12-based applications. Standard logging tools are typically used for this, depending on project preference. On the other hand, changes in business logic also need to be monitored. Since A12-based applications are always integrated into professional project environments, all changes are documented by version management systems.

Conclusion

The OWASP Low-Code/No-Code Top 10 is another sign of the increasing prevalence and maturity of the low-code paradigm. Creating awareness of the associated risks is an important step in making application development safer with the support of business analysts and citizen developers.

Because of its particular orientation as an enterprise low-code platform, some of the identified risks are less significant for A12. After all, A12 is not designed for simple apps that can be quickly clicked together, but for full-blown business applications. Every A12 application is developed as part of a professional software project, which has to meet all the usual security requirements for web applications anyway and is supported by security experts.