# Is it safe to share? — the three-fear check

*For a finished (or finished-enough) app or site you're about to give a
public link to. Written in plain words, because the people who need it
aren't security engineers. It covers the three fears that keep
beginners' apps unpublished:*

1. *Is a secret key visible in my page?*
2. *Can one user see another user's stuff?*
3. *Can this run up a bill on me?*

*Run all three before you share the link. Each check has: what you're
actually afraid of, the check itself (steps you can do), a prompt to
make your AI do its half, what "safe" looks like, and what to do if it
fails. Honest scope, up front: this is a beginner self-check. It
catches the three common leaks. It is not a security audit, and a pass
here doesn't mean "secure" — it means "these three doors are shut."*

---

## Fear 1 — a secret key visible in your page

**What you're actually afraid of.** Some keys are house keys: whoever
has one can walk in and run up charges or read everything — those must
live only on a server, never inside a web page. Other keys are more
like the address on a mailbox: they're *meant* to be public (many
services hand you a "publishable" or "anon" key designed to ship in
the page), but they're only safe because the data behind them is
locked down with rules (see Fear 2). Trouble starts when a house key
ends up in the page.

**The check.**
1. Open your app's page, right-click → "View page source" (or open the
   project files) and search (Ctrl/Cmd+F) for: `sk-`, `secret`,
   `api_key`, `password`, `token`. Anything that turns up gets judged
   by the prompt below — finding a word isn't a verdict; *which kind*
   of key it is, is.
2. Give your AI the prompt below and the project's files (or the page
   source).

**The prompt (paste into your AI, with the project attached):**

> List every key, token, and password-like string in this project.
> For each one, say in plain words: (a) what it unlocks, (b) whether
> it is public-by-design (meant to ship in a web page) or secret
> (server-only), and (c) if it's secret and it ships in the page,
> exactly what someone who found it could do with it. Then tell me
> the smallest change that moves each secret key out of the page
> without breaking the app. This exact change and nothing else.

**Safe looks like:** no secret (server-only) key anywhere in what a
visitor's browser downloads; every key that *is* in the page is
public-by-design and named as such, in a list you now have.

**If it fails:** don't share the link yet. Move the key server-side
(the prompt's fix), and treat the old key as burned — rotate it at the
service that issued it, because anything that was public must be
assumed copied.

## Fear 2 — one user seeing another user's stuff

**What you're actually afraid of.** Your app has logins and saved
things — bookings, notes, photos. If the app's data rules are loose,
any logged-in user can peek at everyone else's things, sometimes by
just changing a number in the address bar. This is the most common
real leak in beginner apps, and the easiest to test yourself.

**The check — the two-account test (do it by hand, it takes minutes).**
1. Sign up as **User A** with one email. Create one clearly-marked
   private thing: a booking, a note, a photo — call it "A's test".
2. Copy the address (URL) of that thing's page, if it has one.
3. Log out completely. Sign up as **User B** with a different email.
4. As B, look for A's test thing: browse wherever users' things are
   listed, *and* paste A's copied address directly into the browser.
5. Try the same logged out entirely, in a private/incognito window.

**Safe looks like:** B can't see A's thing anywhere — not in lists,
not by the direct address, not logged out. B sees only B's things.

**If it fails:** don't share the link yet. The fix belongs to your
AI, bounded: "Users can currently see each other's data. The rule
must be: a user can read and write only their own records, enforced
on the server / in the database rules — not just hidden in the page.
Make this exact change and nothing else, then tell me how to re-run
the two-account test to prove it." Re-run the test yourself after
the fix; an AI's "it's fixed" is not the test — the test is the test.

*No logins and no saved user data in your app? Then this fear doesn't
apply to you — say so in your notes and move on. A static page has
nothing of anyone's to leak.*

## Fear 3 — it runs up a bill on you

**What you're actually afraid of.** Your app calls a paid service —
an AI, a maps service, an email sender, image processing. If a call
can be triggered by visitors, or retried in a loop, or left uncapped,
a busy day (or one mischievous visitor) becomes your invoice.

**The check.**
1. List every paid service your app calls. (Don't know? The prompt
   below makes your AI list them.)
2. For each one, open that service's own dashboard and look for its
   spending limit, budget cap, or usage alert — most have one; set
   it to a number you could shrug at. A cap you set beats a surprise
   you didn't, every time.
3. Ask the loop question (in the prompt): what in this app could
   call a paid service over and over — a retry, a refresh, a bot
   hammering a button?

**The prompt:**

> List every paid or metered service this app calls, and for each
> one: what triggers a call, whether anything limits how often it
> can be called, and the worst realistic bill in a bad day. Then
> name the smallest changes that put a ceiling on each one — a
> per-user limit, a retry cap, a cache — this exact change and
> nothing else. Plain words; I am not a developer.

**Safe looks like:** every paid call has a ceiling you chose — a
provider-side cap, a limit in the app, or both — and you know the
worst-day number before it happens.

**If it fails:** set the provider cap first (that's yours to do and
takes minutes), then apply the prompt's bounded fix before sharing
widely. A friends-only link while a fix is pending is a reasonable
middle state; a public launch isn't.

---

## After the three checks

- All three pass → share the link. Keep the list of keys (Fear 1)
  and your caps (Fear 3) somewhere in your project notes; you'll
  want them at the next change.
- Anything failed and got fixed → re-run that check yourself. The
  check is the proof; the fix's description isn't.
- Something broke and you can't read the error → that's the
  first-aid lane: https://boundedagentharness.com/first-aid
- Want an independent verdict on the whole app before sharing →
  https://boundedagentharness.com/review grades the work against
  your requirements with a different model.

*This checklist is part of Bounded Agent Harness
(https://boundedagentharness.com). Plain words on purpose.*