# Is the app I made with AI safe to share? A 20-minute check before you send the link

Six checks to run before you send people a link to an app you built with Lovable, Replit, Bolt or a similar builder: what it stores, who can read each table, secret keys, and a test as a stranger.

Guides · v1.0 · draft · https://hayzlabs.com/guides/before-you-share-an-app-you-made/

In short:
- Ask first whether it needs to be public at all; a private link, a password or a shared sheet may do the job.
- Run the builder's security scan, turn on row-level security for every table, and keep secret keys out of the app's code.
- Then test as a stranger: a private window, a second account, and a try at reading the first account's data.

## Short answer

Before you send the link, check six things: does it need to be public, what personal data it holds, who can read and change each table, whether any secret keys are in the code, whether a stranger can see someone else's data, and how people can reach you or delete their data. Most builders now have a security scan; run it, but do not stop there, because the builders themselves say a scan is not a guarantee. The single most useful test is to sign up as a second person and try to see the first person's records. If you can, so can anyone.

**Who this is for.** You made a small app with a hosted AI builder (one that puts your app and its database on the public web for you), such as Lovable, Replit or Bolt, for a club, a class or your family. If your project runs only on your own computer, [Coding agents for people who don't write code](https://hayzlabs.com/guides/coding-agents-for-non-coders/) covers that; this page starts at the moment you share it.

## Why this matters

The common failure is simple: the app's database lets anyone read rows they should not. As reported by [The Next Web (21 April 2026)](https://thenextweb.com/news/lovable-vibe-coding-security-crisis-exposed) (news):

- Moltbook, a social network built by vibe coding (building an app by describing it to an AI), exposed 1.5 million API tokens (keys that let a program act as you) and 35,000 email addresses in January 2026, through a Supabase database with no row-level security.
- One Lovable-hosted education app exposed 18,697 user records in February 2026, according to the researcher who found it.
- A May 2025 study, not named in the article, found 170 of 1,645 sampled Lovable apps let anyone read personal information.

The builders have had problems too. In April 2026 a researcher showed that, for 48 days after he reported it, any free Lovable account could read other users' public projects, including code, AI chat history and any database keys written into the code. Lovable disputed calling it a breach, then fixed a February change that had caused it ([The Register, 20 April 2026](https://www.theregister.com/2026/04/20/lovable_denies_data_leak/), news). Lovable says it made projects private by default in December 2025.

## The 20-minute check

> [!OUR RULE]
> The order and timings are our suggestion. Do every step before the first person outside your household gets the link.

**1. Does it need to be public? (2 minutes).** If only five people will use it, a private or workspace-only project, a password, or even a shared spreadsheet may be enough. Lovable's own guidance for apps that should not be public is to set project access to workspace and confirm the app is not published publicly ([Lovable docs](https://docs.lovable.dev/tips-tricks/security-best-practices), vendor help).

**2. List what it stores (3 minutes).** Write down every kind of personal data it keeps: names, emails, phone numbers, children's details, payments. Delete any test data that uses real people's details. If it stores something you do not need, ask the agent to remove that field.

**3. Run the builder's scan (3 minutes).** As of October 2026:

- **Lovable** runs a quick scan when you publish. It checks for tables without row-level security, rules that let everyone through, and known flaws in add-on code. A deep scan you start yourself checks the code for access gaps, leaked secrets and exposed personal data. Lovable says these tools "cannot guarantee complete security" ([Lovable docs](https://docs.lovable.dev/features/security), vendor help).
- **Replit** runs a security scan before publishing, and has a Security Center in the Tools pane. Its Agent security scan is for paid builders ([Replit docs](https://docs.replit.com/replit-workspace/workspace-features/security-scanner), vendor help).
- Other builders: look for "security" in the settings or help pages. If there is no scan, the next steps matter more.

Fix every Critical finding before you share.

**4. Check who can read each table (5 minutes).** Row-level security, or RLS (rules inside the database about who can see and change which rows), is the setting that most often goes wrong. Supabase, the database many builders use, says to "Enable RLS on every table in an exposed schema," and that once it is on, no data can be read through the public key until you add rules ([Supabase docs](https://supabase.com/docs/guides/database/postgres/row-level-security), vendor help). Lovable says it sets up basic rules automatically, but you should review them ([Lovable docs](https://docs.lovable.dev/tips-tricks/security-best-practices)). Ask the agent in plain words:

```text title="Table access check · v1.0"
List every table in this app's database. For each one, tell me:
1. Is row-level security turned on? Yes or no.
2. Who can read rows: anyone, any signed-in user, or only the user who
   created the row?
3. Who can add, change or delete rows?
Show this as a table. Do not change anything yet.
Then tell me which tables would let one signed-in user see or change
another user's data, and what rule would stop that.
```

Read the answer. Any table that holds personal data should say "only the user who created the row" (or only you, the admin). Ask the agent to fix anything else, then run the prompt again.

**5. Look for secret keys (3 minutes).** A secret key is a password for a service, such as a payment, email or database admin key. Lovable warns that "Secrets stored in frontend code are visible to users and should be considered compromised" ([Lovable docs](https://docs.lovable.dev/tips-tricks/security-best-practices)), and Supabase says never to use its secret key in the browser. Ask the agent: "Is any secret key written into the app's code or a public repository? List each one and where it is." Move each into the builder's Secrets setting. If a key was ever in public code, make a new one in that service and delete the old one; GitHub's advice is to "rotate the affected credential immediately" ([GitHub docs](https://docs.github.com/en/code-security/secret-scanning/introduction/about-secret-scanning), vendor help).

**6. Test as a stranger (4 minutes).** This is the check for broken access control (users reaching data that is not theirs), which OWASP, a security nonprofit, ranks first in its [Top 10](https://owasp.org/Top10/A01_2021-Broken_Access_Control/) list of web app risks (2021 edition).

1. Open the link in a private or incognito window.
2. Without signing in, try every page. Can you see anyone's data?
3. Sign up as a second person with a different email.
4. Try to find, open or change the first person's records. If the web address has a number or code in it (such as `/entry/12`), change it to another number and see what loads.
5. If you can see anything that is not yours, stop, fix it with step 4, and test again.

## Before and after you share

- Add a line saying who runs the app and how to contact you.
- Give people a way to ask for their data to be deleted, and do it when asked.
- Set a date in your calendar to switch the app off if nobody is using it.
- Re-run steps 3 to 6 after any big change you ask the agent for.

What not to put in an app in the first place, such as health or ID details, is covered in [What not to paste](https://hayzlabs.com/start/what-not-to-paste/).

> [!CHECK]
> The scan shows no Critical findings, the table check shows every personal-data table locked to its owner, no secret key is in the code, and your second account could not see or change the first account's data.

## Limits

> [!LIMIT]
> This check catches common, simple mistakes. It is not a professional security review, and we have not audited any builder. Builder menus and scans are described as of October 2026 and change often. If your app takes payments, holds health or children's data, or will have many users, pay for a professional review, as Lovable itself recommends for sensitive apps. The incident figures are as reported in news articles, not independently confirmed.

## Sources

1. The Next Web. Lovable's vibe coding security crisis, 21 April 2026. News. [Link](https://thenextweb.com/news/lovable-vibe-coding-security-crisis-exposed)
2. The Register. Lovable denies data leak, 20 April 2026. News. [Link](https://www.theregister.com/2026/04/20/lovable_denies_data_leak/)
3. Lovable. Security overview, read October 2026. Vendor help. [Link](https://docs.lovable.dev/features/security)
4. Lovable. Security best practices for Lovable apps, read October 2026. Vendor help. [Link](https://docs.lovable.dev/tips-tricks/security-best-practices)
5. Replit. Project Security Center, read October 2026. Vendor help. [Link](https://docs.replit.com/replit-workspace/workspace-features/security-scanner)
6. Supabase. Row Level Security, read October 2026. Vendor help. [Link](https://supabase.com/docs/guides/database/postgres/row-level-security)
7. GitHub. About secret scanning, read October 2026. Vendor help. [Link](https://docs.github.com/en/code-security/secret-scanning/introduction/about-secret-scanning)
8. OWASP. A01:2021 Broken Access Control, 2021. Nonprofit security standard. [Link](https://owasp.org/Top10/A01_2021-Broken_Access_Control/)