Stop Your App from Giving Away Passwords and Payment Keys
Your published app gives every visitor files needed to show its screens. Check that those files do not contain passwords, payment keys, or codes that can expose customer information or create charges.
before you start
Anything sent to a visitor’s browser can be examined and copied.
Understand what every visitor receives
in plain words
Your app sends files to each visitor’s browser. Those files must not contain a password, payment key, or code that grants important permissions.
A published app may look like a simple booking page, store, or dashboard. To display it, the visitor’s browser receives instructions, images, text, and settings. Anyone can examine the files delivered to their own device. This is a normal feature of the web, not proof that someone broke into the app. Hiding a password behind a button, an unclear file name, or a screen that requires sign-in does not make the downloaded password safe.
The practical rule is simple: everything sent to a visitor must be safe for any person to read and copy. A password, payment key, database password, email-service key, or paid AI-service key fails that test when it can reveal customer information, change records, send messages, or create charges. Developers call the collection of files delivered to the browser a frontend bundle. That technical name is useful when asking an AI builder what it sends to visitors.
- ▸Treat every file received by a visitor’s browser as publicly readable.
- ▸Allow only settings that cannot expose information, change records, send messages, or spend money.
common risk
A booking page includes an email-service key so the page can send confirmations. A visitor finds the key in the downloaded files and uses it to send messages charged to the app owner’s account.
what to do now
Write down every password and key used by the app. Beside each one, record whether it can reveal customer information, change records, send messages, or create paid usage.
ask your AI
Review my entire app for passwords, payment keys, database passwords, email-service keys, and paid AI-service keys that may be included in files sent to visitors. For every finding, state the file or setting where it appears, whether a visitor can copy it, and exactly what it can do. Do not reveal the full values in your response. Give me a safe correction plan for every dangerous finding.
Judge a key by what it can do
in plain words
A harmless-looking label does not make a powerful key safe. Check whether it can reveal information, change something, send messages, or spend money.
AI builders often place setup information in configuration files. You may see labels such as public setting, browser setting, client setting, or environment variable. Those labels do not decide whether an item is safe. Ask what the item actually permits. If it can reveal customer information, change a record, issue a refund, send email, or use a paid account, visitors must not receive it. A label can describe where an item is stored without describing the power it carries.
Developers call a password, key, or code that proves permission to a service a credential. Some providers deliberately supply a key that may be shown publicly, such as one used only to display a map. Even then, follow the provider’s instructions and restrict where it works, what it can do, and how much it can use. A payment key with refund powers or a database password is different: it must stay in the app’s protected area.
- ▸Check the power of each password or key instead of trusting its label.
- ▸Apply provider restrictions and usage limits even to keys designed for public display.
common risk
An app builder places a payment key in a file named public settings. The name sounds harmless, but the key can create refunds and charges.
what to do now
For every item in the app’s configuration, ask the provider or your AI builder whether visitors can receive it and what actions it permits.
ask your AI
Create a table of every configuration item in my app. For each item, explain in plain language whether visitors receive it, what it permits, whether the provider says it may be public, and which provider restrictions should be enabled. Flag every password or key that can expose customer information, change records, send messages, issue refunds, or create paid usage.
Keep powerful keys behind a protected door
in plain words
A visitor can request a payment or message without receiving the key that performs it. The protected part of the app should hold the key and check every request.
Your app can still accept a payment, send a confirmation, use paid AI, or look up a customer record without placing a powerful key in the visitor’s browser. The visible screen sends a limited request to a protected part of the app. That protected part confirms who is making the request, decides whether that person may perform the action, checks the supplied information, and only then uses the stored key. The visitor receives the result, not the key.
Think of a shop counter. A customer may ask an employee to retrieve an item, but the customer does not enter the stockroom or take the cash drawer. The technical name for the protected area is the backend, and developers also describe work performed there as server-side code. Moving a key there is only one part of the job. That code must also verify permission and limit each request instead of trusting that a visible button can only be used as intended.
- ▸Let the visible screen request one clearly defined action.
- ▸Let protected code hold the powerful key, validate the information, and verify permission.
common risk
A writing app sends the owner’s paid AI-service key to every browser. A visitor copies it and creates paid usage outside the app.
what to do now
Move every task that uses a powerful key into protected code, then require a signed-in person and a permission check whenever the task concerns customer information or money.
ask your AI
Change my app so no browser receives a password or key that can read customer information, change records, send email, process payments, issue refunds, or use a paid AI service. Put those values in protected server-side storage. Send each task through server-side code that validates the submitted information, confirms the signed-in person, verifies permission for the exact action, and returns only the necessary result. Show me the files changed and a test for each protected task.
Replace anything that may have been copied
in plain words
Removing a password or key from today’s files does not disable copies that people may already have. Replace it and turn off the old one.
If a password, payment key, database password, email-service key, or paid AI-service key appeared in a public app, shared preview, or project copy available to other people, assume someone could have copied it. Remove it from files sent to visitors, but do not stop there. Create a replacement through the provider, place the replacement in protected storage, confirm that the app works, and then disable the old item. Do not paste either value into chat messages or reports.
The technical name for replacing a key and retiring the old one is key rotation. This matters because editing the app does not erase copies already downloaded, saved in an old version, or recorded by another service. Review the provider’s recent activity for unfamiliar messages, payments, information requests, or paid usage. If anything is unexplained, preserve the relevant dates and records, contact the provider’s support team, and follow its instructions for securing the account.
- ▸Replace a potentially copied password or key instead of merely hiding it.
- ▸Review recent provider activity before and after disabling the old item.
common risk
An owner removes a paid AI-service key from the current page but leaves that same key active. Someone who copied it from an earlier preview can continue creating charges.
what to do now
Create replacements, update protected storage, test normal app actions, disable the old items, and review recent activity with each provider.
ask your AI
A password or key may have appeared in my published app or a shared preview. Build a step-by-step replacement checklist for every affected provider. Identify where my app currently reads each item, change it to protected server-side storage without printing the values, provide tests that confirm the replacements work, and tell me exactly where I must manually disable each old item and review recent account activity.
Check the real app now and after every change
in plain words
A project that looks safe in the editor can still publish the wrong files. Test the real address before launch and repeat the check when the app changes.
Before inviting customers, open the real published address in a private browser window. Try ordinary actions such as signing in, sending a contact request, starting a payment, or using a paid AI feature. Confirm that they still work after powerful keys have moved into protected storage. Ask your AI builder to inspect the exact production build, meaning the final version prepared for visitors, rather than reviewing only the editor preview or the original project files.
One clean check does not cover future updates. A redesign, provider change, or newly added feature can put a password or key back into files delivered to visitors. The technical name for repeated checks over time is monitoring. VibeCodeWall checks the public app from the outside and watches for important changes; it does not see private code. Combine that outside view with reviews inside your AI builder whenever you change payments, messages, customer information, or paid services.
- ▸Test the exact public address that customers will open.
- ▸Repeat the review after changes involving money, messages, customer information, or paid services.
common risk
The launch version is clean, but a later contact-form update sends an email-service key to the browser. Without another check, the owner may not notice the change.
what to do now
Make the public-address test, the AI builder review, and ongoing outside checking part of every launch and important update.
ask your AI
Before I publish this version, inspect the exact files that will be sent to visitors. Confirm that they contain no password, payment key, database password, email-service key, or paid AI-service key that can expose information, change records, send messages, or create charges. Do not print any full values. Then give me a pass-or-fail launch checklist for signing in, contact messages, payments, customer records, and paid AI features, including only features that exist in my app.
Quick checklist
- 01List every password, payment key, database password, email-service key, and paid AI-service key used by the app.
- 02Ask your AI builder which listed items are sent to a visitor’s browser.
- 03Move every item that can expose customer information, send messages, change records, or create charges into the protected part of the app.
- 04Replace any password or key that appeared in a published app, public preview, or shared project copy.
- 05Test the real published address in a private browser window before inviting customers.
- 06Use separate, limited keys for testing and for the live app.
- 07Turn on spending limits, usage alerts, and restrictions offered by payment, email, map, and AI providers.
- 08Have VibeCodeWall check the public app from the outside and watch for important changes over time.
FAQ
Can an unclear file name hide a powerful key?
No. A visitor can inspect the files received by the browser regardless of their names. Any password or key that can expose information, change records, send messages, or spend money belongs in the protected part of the app.
Can I leave a testing key in the published app?
Only if the provider explicitly designed it for public display and its restrictions make the result acceptable. Otherwise keep it protected. Testing keys can still create unwanted activity, so use separate items with strict permissions, limits, and alerts.
What if I cannot tell whether a key appeared publicly?
Treat it as possibly copied until you confirm otherwise. Ask the AI builder to inspect the files sent to visitors. If the item appeared in a public or shared version, replace it and disable the old one.
Does VibeCodeWall read my private project?
No. VibeCodeWall checks the public app from the outside and can watch that public version for important changes over time.