Is your AI-built dashboard open to anyone?

Fast to build, easy to leave open

AI app builders and coding assistants can produce a working dashboard in an afternoon. What they produce is usually a front end that talks straight to a database. Whether strangers can read that database depends on settings that are easy to skip when the goal is "make it work".

This is not hypothetical. In 2025, a public vulnerability record (CVE-2025-48757) described apps generated with one popular AI app builder where an insufficient database row-level security policy could let remote, unauthenticated visitors read or write database tables. The vendor disputes the record, saying each customer is responsible for protecting their own app's data. That dispute is the point: if you built it, checking it is on you.

The checks below take about 20 minutes. You need a browser and access to your database dashboard. Only test tools you own or are authorized to test.

1. The private-window test (2 minutes)

The simplest check is the one most often skipped.

1. Open a private or incognito window, so you are not logged in anywhere.
2. Paste the URL of your tool's main page.
3. Then paste the URLs of inner pages directly: /admin, /dashboard, /settings, /users, a report page, an export link.

Good looks like: every page sends you to a login screen, and after the redirect no data appears, not even for a second.

Red flags:

• Any page shows real data without a login.
• The page flashes data and then redirects. The data was already sent to the browser.
• The login page is just a screen in front of a data request that already ran (see check 3).

2. Is the login enforced on the server? (5 minutes)

Many generated apps check "is the user logged in?" only in the browser. A browser check hides the page, but the data request behind it can still be called directly.

1. Log in to your tool normally, open the browser's developer tools (F12, or right click and Inspect), and go to the Network tab.
2. Reload the page and find the requests that return your data (filter by Fetch/XHR). Look for JSON responses with customer names, emails or numbers.
3. Right click one request and Copy as cURL.
4. In a terminal, run that command without the Authorization header and without cookies (delete those lines from the copied command).

Good looks like: the request returns 401 or 403, or an empty result.

Red flag: the same data comes back with no login. Anyone who finds that URL can read it.

Also check roles: log in as a normal user and try the admin URLs. A regular user should not see other users' records just by changing an ID in the URL (for example /orders/1041 to /orders/1042).

3. Supabase: row-level security left off (5 minutes)

Many AI-built tools use Supabase. In Supabase, the browser uses a public key (the anon or publishable key) to talk to the database directly. That key is designed to be public. What protects your data is row-level security (RLS), a database rule that decides which rows each user may read or change.

Supabase's own documentation is clear: a table in an exposed schema without RLS is readable and writable by any role with a grant on it, and by default that can include anonymous visitors. Their instruction is to enable RLS on every table in an exposed schema.

Check:

1. In the Supabase dashboard, open Advisors, then Security Advisor. Look for these findings:
2. rls_disabled_in_public: a table in the public schema without RLS.
3. auth_users_exposed: user account data exposed through a view.
4. security_definer_view: a view that bypasses RLS.
5. Open Table Editor. Every table in the public schema should show RLS as enabled.
6. For tables with RLS enabled, open the table's policies list in the dashboard and read each policy. A policy whose condition is simply true lets everyone through and is no better than RLS off.

Good looks like: RLS on for every public table, policies that tie rows to the logged-in user (for example auth.uid() = user_id), and an empty Security Advisor.

Red flags: any rls_disabled_in_public finding, policies using true, or tables you did not know existed (generated apps often create extra tables).

Firebase users: the same idea applies to Firestore and Storage security rules. Rules that allow read, write for everyone, often left over from test mode, mean the data is public. Check them in the Firebase console under each product's Rules tab.

4. Secret keys in the front end (5 minutes)

Anything shipped to the browser can be read by anyone. Public keys are fine there. Secret keys are not.

Check:

1. Open your tool, open developer tools, and go to the Sources tab (or Debugger in Firefox). Use the search across all files (Ctrl+Shift+F or Cmd+Option+F).
2. Search for patterns that usually mean a secret key:
3. service_role or sb_secret_ (Supabase server keys)
4. sk_live_ (Stripe secret keys; pk_live_ is the public one and is fine)
5. sk- (several AI providers use this prefix for API keys)
6. AKIA (AWS access key IDs)
7. PRIVATE KEY, secret, password
8. In your code repository, search for the same strings, and check your hosting platform's environment variables. Variables with a public prefix (such as NEXT_PUBLIC_ or VITE_) are bundled into the browser code on purpose.

Good looks like: only public keys in the browser, and all secret keys in server-side environment variables.

If you find a secret key: treat it as leaked. Create a new key, update your server, and revoke the old one at the provider. Removing it from the code is not enough, because old versions of the site and your repository history may still contain it. Then set a spending limit or alert at that provider.

If your code is on GitHub, turn on secret scanning for the repository so future leaks are flagged.

5. Shared links and public files (3 minutes)

Internal tools often grow side doors.

• Share links to dashboards, reports or files: do they expire? Can anyone with the link open them? Do they still work for people who left?
• Storage buckets (Supabase Storage, S3, Firebase Storage): is any bucket set to public that holds invoices, exports or user uploads?
• Preview and staging URLs from your hosting platform: are they protected, or do they show production data to anyone who guesses the URL?
• Spreadsheets and docs connected to the tool: who is on the share list?

Good looks like: links expire, buckets with private data are private, previews are protected or use test data, and share lists match your current team.

The printable checklist

When you are done

Write down which tools exist, who built them, what data each one touches and who should have access. AI-built tools multiply quickly, and the ones nobody remembers are the ones that stay open.

The 2-minute check covers open internal tools and keys in the wrong places, along with backups and access, and gives you one fix for each gap.

Want a second pair of eyes?

With your permission, the free review checks which of your tools can be reached without a login and where keys are exposed, using view-only access. You get a short written report and can do every fix yourself.

Sources

• NVD: CVE-2025-48757
• Supabase: Row Level Security
• Supabase: Database Advisors (Security Advisor lints)
• Supabase: Understanding API keys
• Firebase: Get started with Cloud Firestore Security Rules
• Stripe: API keys
• GitHub: About secret scanning
• OWASP Top 10: Broken Access Control

From keelops.co/ai-built-tools-check. Free to print and share.