Keep passwords and access keys out of files people can download
If your app sends passwords and access keys to a visitor’s browser, they are no longer private. This guide explains what that means, why it matters, what to check before launch, and how to ask your AI builder to fix risky setup.
before you start
Before launch, make sure your app only sends public, low-risk values to a visitor’s browser and keeps passwords and powerful access keys in a place visitors cannot download.
What it means when passwords and access keys reach a visitor
in plain words
When your app opens in someone’s browser, it sends files to that person’s device. If those files contain a password or access key, that value can be read, copied, and shared.
Many new app owners assume a value is private because it came from a settings screen or because an AI tool placed it into the app for them. That is not enough. If the app sends that value to a visitor’s browser, the visitor can inspect it. The simple rule is this: if a person can download it, you should assume they can read it. Developers call the downloaded app files the frontend bundle, but you do not need the term to use the rule safely.
This matters because some values are harmless to show and some are powerful. A public map identifier or a basic site setting may be fine if it was designed to be visible and can do very little. A password or access key that unlocks data, billing, storage, messages, or admin actions is different. That kind of value should live only on your server, which means a place your visitors cannot download from directly. Developers call this server-side code. If a browser can see a powerful access key, treat that as a launch problem and fix it before launch.
- ▸If a visitor’s browser receives a value, assume the visitor can read it.
- ▸Some visible values are intentionally public, but passwords and powerful access keys are not.
- ▸Passwords and powerful access keys belong in server-side code, not in browser-downloaded files.
common risk
A founder pastes a payment, database, or file-storage key into an AI builder because the app asks for it. The app works in testing, but the same value ends up inside files every visitor downloads when opening the site.
what to do now
Make a list of every password, access key, and access code your app uses. Mark each one as safe to show publicly or not safe to show publicly. Anything in the second group must be moved out of browser-downloaded files before launch.
ask your AI
Audit my app for any password or access key that is being sent to the visitor’s browser. Explain in plain language which settings are intentionally public and which passwords or access keys can open data or spend money and must stay hidden. For every risky value, move it out of browser-downloaded code into server-side code, update the app so the browser only receives the minimum result it needs, and show me a before-and-after list of what changed.
Why this matters before you launch
in plain words
A password or access key in public app files can let the wrong person use services, read data, or learn too much about how your app is set up.
Before launch is the best time to check because public files are easy to copy once the app is live. A single pasted value can give more access than you intended, or it can reveal internal names and addresses that make your app easier to map. You do not need to imagine extreme scenarios to care about this. Even a simple mistake can create clean-up work: changing keys, fixing settings, rebuilding the app, and checking whether any access should be reviewed.
There is another common issue besides the obvious password or access key itself: helper files meant for developers. Sometimes apps publish extra files that make the code easier to read while finding errors. The technical name is source maps. These files do not always contain a dangerous value, but they can reveal file names, app structure, comments, and other details you did not mean to share. That is why a launch check should look at the actual public output of the app, not only the original project files inside your editor.
- ▸Fixing exposure before launch is easier than cleaning it up after launch.
- ▸Public app files can reveal both powerful access keys and extra internal details.
- ▸Check the published output, including optional developer helper files.
common risk
An app launches with public helper files turned on. No obvious key appears at first glance, but the helper files reveal internal file names, old comments, and test pages that were never meant for visitors.
what to do now
Review the built public version of your app, not just the project you see in the editor. Check whether optional helper files are exposed and remove them unless you truly need them.
ask your AI
Create a before-launch check for my app. Build the app in the same way it will be published, inspect the public output, search for passwords and access keys, internal addresses, test accounts, comments, and developer helper files. Tell me clearly what is safe, what is risky, and make the code changes needed so risky values and unnecessary helper files are not publicly reachable.
A common setup mistake
in plain words
The most common mistake is giving the browser direct access to something powerful when only your app’s private side should have that access.
A beginner-friendly way to think about this is to split your app into two places. One place is what visitors receive and can inspect. The other place is where your app can safely keep stronger permissions. If the visitor-facing part talks directly to payments, data storage, admin tools, or messaging systems using a powerful password or access key, that password or access key often ends up exposed. Developers call the visitor-facing part the frontend and the private side the backend, but the safer rule is simpler than the vocabulary: visitors should not receive powerful keys.
A better pattern is to let the browser ask your own app for a result, and let your app’s private side talk to protected services. Then the browser gets only the result it needs, not the powerful value that made the request possible. This also makes later reviews easier. If your AI builder or a third-party tool asks you to paste a powerful key into code that runs in the browser, stop and ask for a safer design. Often there is one, and your AI tool can usually refactor the app for you.
- ▸Do not give browser-downloaded code direct access to powerful services.
- ▸Let your app’s private side make protected requests instead.
- ▸If a tool asks for a powerful key in browser code, question the design.
common risk
A site needs to upload files. Instead of sending the upload request through the app’s private side, the builder places a powerful storage key into browser code so uploads work faster during testing.
what to do now
Change risky direct connections so visitors talk to your app first. Let your app’s private side handle the powerful access and return only the needed result.
ask your AI
Refactor my app so browser-downloaded code does not use any powerful private key directly. Move protected requests to server-side code, keep only truly public values in visitor-facing code, narrow permissions wherever possible, and explain each change in plain language for a beginner.
What to do now and after launch
in plain words
Do one careful check before launch, then keep watching the public app because later changes can bring the same problem back.
Your final check should be boring and repeatable. Build the app as if you were releasing it today. Search the generated public files for values that look like keys, private access codes, passwords, private addresses, internal names, and test data. Remove development messages and temporary notes. Confirm that every visible value was meant to be public and has very limited power. If you are unsure about any value, treat it as private until proven otherwise and keep it out of browser-downloaded files.
After launch, keep monitoring from the outside because app changes can reintroduce the same issue. A fast fix, a copied setting, or a new added tool can make a password or access key public again. VibeCodeWall helps by checking the public app from the outside and watching for important changes over time, such as newly visible values, new public paths, technology clues, and known weaknesses. It is not reading your private code. It is checking what the public app reveals. That outside view is useful because visitors and automated scanners only see the public side too.
- ▸Use the same pre-launch check every time you prepare to publish.
- ▸Treat uncertain values as private until you confirm they are safe to show.
- ▸Keep outside-in monitoring on after launch because later changes can reintroduce exposure.
common risk
Months after launch, a quick update adds a copied setting to visitor-facing code. Nobody notices because the app still works, but the public site now exposes a powerful access key until an outside check catches the change.
what to do now
Create a repeatable publication checklist and keep external monitoring on after launch so you can catch new exposure quickly.
ask your AI
Make me a complete pre-launch and post-launch safety workflow for this app. Include a check of the version prepared for publication, a search for exposed passwords and access keys, a review of visible settings, removal of development data, verification that only low-risk public values reach the browser, and a recurring reminder to recheck after important changes. Present the workflow as a simple checklist I can follow every time.
Quick checklist
- 01Prepare the app the same way you plan to publish it, then inspect the generated public files.
- 02Search those files for private keys, private access codes, internal site addresses, test accounts, and copied notes.
- 03Review every app setting and decide whether it is truly safe for visitors to see.
- 04Keep passwords and powerful access keys in server-only code, not in code sent to the browser.
- 05Check whether developer helper files are publicly reachable and turn them off if you do not need them.
- 06Remove test data, development messages, and temporary values before launch.
- 07Repeat the check after important app changes, not only once.
- 08Use outside-in monitoring that checks the public app and watches for important changes over time.
FAQ
Is every app setting private?
No. Some settings are meant to be public, such as a basic visible identifier with very limited power. But if a setting can unlock data, storage, billing, messages, or admin actions, treat it as private and keep it out of browser-downloaded files.
If I change a leaked key quickly, is that enough?
Changing it is important, but it is only part of the fix. You also need to remove it from public app files, rebuild, and check whether the new published version still exposes anything similar.
How do I know whether a value is safe to show?
Ask what a stranger could do with it. If it only labels a public service and has tight limits, it may be acceptable. If it grants access or stronger permissions, it should stay on the private side of your app.
Why look at the published files instead of only the editor?
Because mistakes often appear during the process that prepares and publishes the app. The files the visitor downloads are what matter, so that is what you should inspect.