Article partially generated by artificial intelligence.
TL;DR: OWASP Top 10 is the list of the most serious risk categories in web applications, published by the OWASP Foundation and used as a reference by security teams and auditors. Apps built with AI, for example in Lovable on a Supabase database, usually fail in the same places the OWASP Top 10 describes, above all in access control. Below is a 12-point application security checklist to run before an app starts handling customer data, or before an auditor asks about it in a company covered by NIS2.
The checklist is part of the full overview of NIS2 software requirements.
Key facts:
The OWASP Top 10 is published by the OWASP Foundation, a non-profit focused on application security. It describes the ten risk categories that most often lead to incidents in web applications, from broken access control and security misconfiguration to vulnerable components, injection and missing logging.
Vibe-coded apps do not have new kinds of flaws. They have the same ones, more often, because an AI model writes code that works and has to be asked for security. That makes the OWASP Top 10 a good backbone for a checklist. For why such apps appear in companies and fall under NIS2, see why shadow AI apps end up in NIS2 scope.
Lovable and similar tools often connect an app to a Supabase database. It is convenient, but it carries a specific risk: the database’s public key is visible in browser code by design, so all data protection rests on Row Level Security rules. If the rules are missing or too broad, anyone who knows the app’s address can read the tables. Supabase’s documentation explains how to configure Row Level Security. Check this first; it is the most common source of leaks in AI-built apps.
If the app itself calls a language model, for example to answer customers or summarise documents, it adds the risks described in the OWASP Top 10 for LLM Applications: prompt injection, sensitive data disclosure in model output and excessive agency of the tools the model can use. Google Trends shows interest in this list rising fast. The minimum is to separate data from instructions, limit permissions and avoid sending the model data it does not need.
A checklist catches the most common mistakes, but it does not replace a code review or a penetration test, in which a specialist tries to break into the app the way an attacker would. For apps that handle customer data or connect to company systems, plan both. In a company covered by NIS2, the review result is also evidence for the auditor. If an outside vendor built the app, use the same checklist when you assess them; see third-party risk management for software vendors.
A review of a small AI-built app can fit into one working day if it is prepared in advance. You need access to the code or to the project in the tool it was built with, access to the database and hosting dashboards, and an hour with the person who built the app.
The same problems keep appearing in AI-built apps. Tables without Row Level Security are fixed by enabling RLS and adding policies that let users read only their own records. An admin-level key in browser code must be rotated at once, and operations that need it moved to the server. API endpoints that take a record ID and return data without checking that it belongs to the signed-in user are a textbook case of broken access control, the first category of the OWASP Top 10; the fix is a server-side check. Missing rate limits are solved at the hosting platform or API gateway level.
Most of these fixes take hours, not weeks. The harder part is often the organisational decision: whether a tool that started as an experiment and now serves hundreds of customers should be rebuilt and taken over by IT. That decision should be made deliberately, with the business owner involved, not after the first incident.
Commission a penetration test when the app processes personal data of many customers, handles payments, connects to production systems or is publicly reachable by anyone. In those cases the checklist is a starting point, not the finish line. A tester chains small weaknesses into a realistic attack, which no checklist does. Fix the checklist findings first and then order the test, so the report focuses on the harder issues rather than gaps you could have found yourself. In a company covered by NIS2, test results and a list of fixes are also strong evidence for the auditor. When choosing a tester, ask about scope, methodology, a sample report and whether a retest after fixes is included.
Sanddev reviews AI-built apps against the OWASP Top 10, fixes what it finds and prepares a board-level report. See what a full production-readiness review involves.
The OWASP Top 10 is a list of the ten most serious risk categories in web applications, published by the OWASP Foundation. Security teams, developers and auditors use it as a reference; broken access control is ranked first.
They can be, if someone checks the configuration. Lovable apps often use Supabase, and data security then depends on Row Level Security rules. Without them, anyone who knows the app’s address can read the tables.
Check that every table holding data has Row Level Security enabled with policies restricting reads and writes, and that the service_role key has not reached browser code or a repository. Supabase’s documentation describes the setup.
No. A checklist based on the OWASP Top 10 catches the most common mistakes, while a penetration test probes the app the way an attacker would and finds issues a checklist does not cover.
The OWASP Top 10 covers risks in web applications. The OWASP Top 10 for LLM applications covers apps that use language models, including prompt injection and sensitive data disclosure in model output.
Third-party risk management is now a legal duty for companies covered by NIS2. Supply chain security is one of the minimum risk-management measures in the directive, and it reaches the companies that write, maintain and host your software.
An SBOM (software bill of materials) is a list of the libraries, modules and versions a product is built from. From 11 December 2027, the Cyber Resilience Act requires manufacturers of products with digital elements to draw up an SBOM in a commonly used, machine-readable format covering at least top-level dependencies.
The Cyber Resilience Act (CRA) has required, since 11 September 2026, manufacturers of products with digital elements to report actively exploited vulnerabilities and severe incidents. An early warning is due within 24 hours of becoming aware, a full notification within 72 hours and a final report later.
