Vibe-to-Production · Security

Is Your AI-Built App Exposing Data? Here's How to Find Out

You shipped something real with an AI tool, then read something alarming about vibe-coded security. You want a straight answer: is my users' data actually reachable by strangers — and how do I find out before hiring anyone?

Get your app assessed ↗See the framework
72 hours
01 / TO FINDINGS
2–6 weeks
02 / TYPICAL FIX WINDOW
500+
03 / ENGINEERS
92%
04 / ON-TIME DELIVERY
SecurityProblem guide

Most data exposure in AI-built applications comes from access rules that exist only in the interface — the app hides other people's records, but the server never checks who is asking. You can confirm or rule this out yourself in about twenty minutes with two browser windows, and a security audit turns whatever you find into a scored, prioritised fix list.

How to recognise it

The signs show up before the incident does.

None of these proves you have the problem. Each one raises the odds — and every one of them is checkable in the twenty-minute protocol below.

  • The app was never asked to be secureYour prompts described features, not access rules. If nobody wrote “users must never read each other's records”, there is no reason to assume the generated code enforces it.
  • Login works, so it feels safeA working login only proves the app knows who you are. Whether it checks what you are allowed to see is a separate mechanism — the one prototypes most often skip.
  • Record numbers appear in your web addressesAddresses like /invoice/1042 are normal. The question is what happens when someone changes that number to 1041 — and nobody has ever tried.
  • One powerful key does everythingThe credential that runs admin features also sits behind ordinary user actions. Convenient in development; in production it means every request carries master access.
  • The app has only ever been used politelyYou and your testers always followed the buttons. Security is about requests that ignore the interface entirely — and nothing has tested those yet.
Why this happens

One missing layer explains every symptom above.

The permission check lives in the screen — not in the server behind it.

Anyone who talks to the server directly, and a browser's built-in developer tools are enough, is never asked the question the interface asks. Whatever the screen hides, the server hands over.

This is not a defect of any one tool — it follows from how prompt-built apps come to exist, and the platform guides show how the same gap surfaces on each stack.

What is actually at stake

It isn't a bug count. It's an open door.

This failure has no partial version: if one record is reachable without permission, every record in that table is. What rests on it is not abstract — customer trust, the data-protection obligations in your contracts, and any enterprise deal or investor diligence that asks the question you have not answered yet.

If something has already gone wrong, the first-response guide covers the first hour. If nothing has — that is exactly the moment this is cheap to fix.

Check it yourself

Run the audit yourself — tonight.

No developer, no tooling, no permission needed — this is your own app. Work through the sheet in order; if a check fails, do it once more before believing it. What you find is yours to act on, with us or without us.

Diagnostic protocolAbout 20 minutesTwo browser windowsNo code required

  1. Can one account read another account's data?

    Run it

    Create two accounts, in two different browsers or one normal plus one private window. In account A, open something only A should see and copy the web address. In the other window, logged in as account B, paste that address and load it.

    What the result means

    B seeing an error or its own data is a pass. B seeing A's record means authorization is not enforced on the server — the severe finding. Confirm it once more, then treat it as real.

  2. Does changing a number in the address change whose data you see?

    Run it

    Logged in as yourself, find any address containing an ID — /orders/1052, ?user=88 — then change the number by one and load the page.

    What the result means

    Your own data or an error page is a pass. Someone else's record means every row in that table is readable by anyone patient enough to count.

  3. Are secret keys sitting in the page for anyone to read?

    Run it

    Open your app, right-click, choose View Page Source, and search the page for “key”, “secret” and “service”. Keys named public, publishable or anon are designed to be there; anything named secret, service or admin is not.

    What the result means

    A privileged key in the page source is a credential every visitor already holds. It cannot be un-leaked — it has to be revoked, reissued and moved behind the server.

  4. Does the app still answer after you log out?

    Run it

    Take the private address from the first check, log out completely, then paste it into the same browser and load it. Try it in a private window too, where you have never logged in.

    What the result means

    A login screen or an error is a pass. Seeing the data while logged out means the endpoint is public — no account is needed to read it, only the address.

  5. Is the admin area protected, or merely unlinked?

    Run it

    While logged in as an ordinary, non-admin account, try the obvious addresses: /admin, /dashboard, /settings, and any admin address you know. Repeat while logged out.

    What the result means

    Hidden is not protected. If an ordinary account can load the admin surface, every privileged action on it is one guessed address away from public.

Each of these maps to a scored item in the production-readiness framework. A pass on all of them rules out the loudest failure class — the full audit covers what a browser can't reach, at a fixed price.

How it gets fixed

Sealed from the data layer up.

The order matters more than the effort: enforcement first, credentials second, proof third. Done in the wrong order, the work gets done twice while the exposure stays open. The same discipline runs through everything we deliver.

Get my scorecard
  1. 01

    Map what is actually reachable

    Before anything changes, engineers enumerate the exposure — which tables, which endpoints, which keys — so the fix list is evidence rather than guesswork. This is the diagnostic audit, with findings in 72 hours.

  2. 02

    Move enforcement into the data layer

    Access rules go onto every table that holds user data, so a request that bypasses the interface hits the same wall the interface shows. This closes the severe findings first.

  3. 03

    Rotate every credential that reached a browser

    Any key that was ever visible to a client is treated as public: revoked, reissued, and relocated behind server-side code where visitors can never read it.

  4. 04

    Prove the denial with tests

    Every access rule gets an automated test asserting the wrong user is refused — not merely that the right one succeeds — so the next feature cannot quietly reopen the hole.

  5. 05

    Add the tripwires

    Rate limiting, session expiry and monitoring that alerts a human — so the next probe is something you read on a dashboard, not something you hear from a customer.

Where it sits in the framework

The framework's heaviest weights sit exactly here.

40 / 100

points of the production-readiness score sit in the categories this problem touches.

See every check and weight
0The full 100-point framework100
  • 20 ptsAuthentication & access controlThe heaviest category, because it is the one failure that exposes every other user's data at once. Nothing else on this list can hurt you as fast.
  • 10 ptsSecrets & configurationA leaked key is not a bug you can patch quietly — it is a credential someone else now holds. Rotation has to be routine.
  • 10 ptsData protection & recoveryBackups that have never been restored are not backups. This category is mostly about proving the recovery path exists.
Our honest read
If your app was built by describing features to an AI tool and nobody ever wrote down who may see what, assume authorization is interface-deep until the two-browser check proves otherwise — it is a twenty-minute question with a scoped, fixable answer, not a rebuild.
FAQ

The questions that follow.

QDo I need to take the app offline while this is checked or fixed?
Almost never. The audit itself is read-only — nothing is changed or deployed while it runs. The fixes, such as data-layer access rules and key rotation, ship like any other release. The one scenario where we advise pausing sign-ups is an actively exploited exposure, and that call is made together on day one, with the evidence in front of both of us.
QMy platform says it handles security. Doesn't that cover this?
Hosting platforms secure the infrastructure — servers, networks, encryption of stored data. Who among your users may see which record is application logic, and only your build defines it. Every hosted platform is explicit about that split; it is in their documentation, not their marketing. So a platform can be doing its job perfectly while your application's own access rules do not exist.
QI ran the self-checks and everything passed. Am I in the clear?
You have ruled out the most common and most severe exposure class, which is genuinely worth knowing. It is not a clean bill of health: session handling, file uploads, webhook verification, what your logs capture and how backups are protected all sit outside a twenty-minute browser test. The full production-readiness framework scores 49 checks across the whole application, and security is only part of it.
QA check failed. What should I do tonight?
Write down exactly what you saw — the addresses, the accounts, the time — and resist two urges: announcing it, and shipping a hurried fix that may widen it. If a privileged key is visible in the page, rotating it at the provider is safe to do immediately. For authorization gaps, the exposure has almost certainly existed since launch; the priority is a correct fix within days, not a risky one at midnight.
QCan't I just prompt the AI tool to fix its own security?
It can write access rules competently when you ask for exactly the right thing. The hard part is the complete list of what to ask for, and verifying that denial actually happens afterwards. That verification loop — attempt the access that must fail, prove it fails, pin it with a test so it stays failing — is the real work of a security audit, whoever ends up writing the fix.
QWhat does a security audit cost, and how long does it take?
The diagnostic audit is fixed-price ($2K – $5K) with findings in 72 hours: a scored report where every finding carries its severity, the evidence behind it, and the specific fix. Closing the findings is a separate, scoped engagement — typically 2–6 weeks — and the report is written so any competent engineering team could execute it, including one that is not us.
Where to go next
Other problems
Before you share anything
Your IP · 100% yours, in writing

Nobody has ever regretted sending us their repository.

Handing private code to anyone is a real decision, so everything below is settled before the audit starts rather than on request.

  1. An NDA is signed and returned before you send a linkStep one, every time
  2. Access is read-only, scoped to one repository, and time-boxedRevoked on delivery
  3. Our copy of your code is deleted when the report landsNothing retained
  4. We build for clients and never launch anything that competes with themNever has happened
No-obligation diagnosis

Send us the repository. We'll tell you what's missing.

Fixed price, 72 hours to findings, and a report you can act on with or without us. Nothing is committed until you have read it.

NDA signed before you send anything · read-only access, revoked when the report lands · our copy deleted on delivery.

4.8/5Clutch4.9/5GoodFirms