Login Path, Data Remains Open: Check Access Rights of AI Applications Before Use by Individuals

Your first application already has a login page. You log in, your notes appear, and others' notes do not. It seems fine.

However, the login screen only answers one question: who you are. The second question, which data you are allowed to read and modify, is kept elsewhere. In AI-built applications, this second part is often the most vulnerable. The vulnerabilities are not visible from the screen.

Number one mistake, not a rare case

OWASP, a widely used web application security reference, places broken access control at the top of the Top 10:2025 list. All applications they tested had at least one form of broken access control. The most useful note from OWASP for beginner application developers: security measures that are only implemented on the front end can be bypassed with a single command from the terminal. A hidden button is not a locked door.

A concrete example is recorded in the NVD, the vulnerability database owned by NIST. CVE-2025-48757 mentions insufficient Row-Level Security policies in Lovable, a platform for building web applications using everyday language, until April 15, 2025. As a result, attackers without login could read or write the database tables of the generated site. The provider disputes this classification: according to them, each customer is responsible for their own application data. Regardless of who is right, the lesson is the same. This issue falls on the application developers.

Keys that may be visible, and those that should not

The example below uses Supabase because its documentation clearly details this issue. The principles apply to any database called directly from the browser.

Two small traps often slip through. First, public-prefixed variables like NEXT_PUBLIC_ are bundled to the browser, so secret keys should never have that prefix. Second, Supabase is phasing out the anon and service_role keys, targeting the end of 2026. If AI or tutorials instruct you to copy a long key starting with eyJ, that guide is written for the old keys.

Three holes not visible from the screen

1. Tables without RLS. Tables in schemas open to the API without RLS can be read and written by any role holding basic permissions (grant). In some projects, new tables in the public schema automatically grant read, add, modify, and delete permissions to visitors who are not logged in. Adding a policy does not revoke those permissions. Supabase recommends revoking all, then granting back only what is necessary.
2. View. Postgres typically creates views with the creator's rights, so views bypass the RLS of the underlying tables. In Postgres 15 and above, set security_invoker = true.
3. Rules that read user_metadata. The contents of that column can be modified by the users themselves. Roles like "admin" are stored in app_metadata, which cannot be changed by users.

Test with two accounts, not one

One account only proves you can see your own data. Try creating account A and account B. Save data as A, then log in as B and change the ID in the page address or in the data request. OWASP refers to this pattern as insecure direct object reference: other people's data is exposed simply by changing the number.

Pay attention to the form of rejection. According to Supabase documentation, rows filtered by policy do not trigger any errors; the result is simply empty. So "no error" does not necessarily mean safe, and "the result is empty" does not prove that data A is still intact. Double-check A's rows after the attempt. For routine testing, Supabase provides supabase test db which tests all four operations per table, plus the Security Advisor in the dashboard.

Audit with AI, testing remains in your hands

Claude Code has the command /security-review that checks for vulnerabilities like SQL injection, XSS, and authentication and authorization flaws, and can be asked to fix them. Claude's help center itself states that this automated check complements, not replaces, manual reviews. Run the audit, then still conduct the two-account test before the application is used by others.

Sources

1. A01:2025 Broken Access Control, OWASP Top 10:2025.
2. CVE-2025-48757 Detail, National Vulnerability Database (NIST), published May 29, 2025, status Disputed.
3. Welcome to Lovable, Lovable Documentation.
4. Row Level Security, Supabase Docs.
5. API keys, Supabase Docs.
6. Automated Security Reviews in Claude Code, Claude Help Center, March 16, 2026.