Stop Strangers from Opening Customer Files

Your app may ask customers for identity documents, receipts, profile photos, contracts, spreadsheets, support screenshots, or completed forms. It may also create invoices, reports, and account exports. These files are usually saved away from the screen where they were submitted. If the saving rules are too broad, a signed-out visitor may be able to open a file by following its address. The sign-in screen alone does not guarantee that the saved file is protected.

Start by listing every file the app receives and creates, including old samples and abandoned test uploads. Note where each file is saved and whether it is meant for everyone, one customer, or a small team. Developers call a file-holding location a storage bucket. A bucket is simply a container used by an app to organize saved files. It is not automatically public or protected; the rules attached to it decide who can reach its contents.

Do not rely on names such as private, internal, or customers-only. A folder name is a label, not a barrier. The important question is what happens when someone tries to open a file. Public product photos can be available to everyone, but identity documents, receipts, contracts, and personal reports normally should not be. Keeping those two groups in separate locations makes mistakes easier to notice and reduces the chance that one broad rule exposes everything.

For every file type, decide which people need it and what each person may do. A customer may need to open their own invoice but should not see another customer's invoice. A support worker may need to view a document for an assigned case but may not need to replace or delete it. Someone allowed to add a file does not automatically need every other ability. Treat opening, adding, replacing, and deleting as four separate choices.

The technical name for a rule that allows or refuses one of these actions is a permission. Good permissions check more than whether someone has signed in. They also check whether the requested file belongs to that customer or whether the team member has a valid work reason to use it. Write the intended rules in ordinary sentences first. This gives your AI builder a clear target and makes the proposed changes easier for you to review.

Create two harmless test accounts so you can check the result without touching real customer information. Upload a plainly labeled sample file with the first account. The second account should not find or open it. Then reverse the test. Also check whether either account can replace or delete the other's file. These tests reveal broad rules that may not be visible while you are using only an owner or team account.

Use only a harmless file that you uploaded through a test account. Open it while signed in, copy its address, and then sign out. Open a private browsing window, which is a fresh window that does not reuse your signed-in session, and try the address again. A customer-only file should be refused. Do not guess addresses, inspect other accounts, or test real customer documents. The goal is to confirm your own rules safely.

Some apps create a short-lived address only after confirming that a customer may receive a file. The technical name is a signed URL. In plain language, it is a temporary download address with an approval mark attached. It can be useful when it expires quickly, is created only for the correct person, and cannot be reused indefinitely. It should not be displayed on a public page or treated as a replacement for correct file rules.

Repeat the check for viewing, downloading, replacing, and deleting whenever those actions exist. Record the expected result before each attempt, such as signed-out visitor is refused or second test customer is refused. If a temporary address is used, note when it was created and confirm that it stops working after the intended period. Save only the result and test-file name; avoid copying real customer information into your notes.

Your app may need a database password, payment key, email access code, or administrator code to perform important work. A database is the organized system where the app keeps records such as customer names and orders. These items can open protected information, create charges, issue refunds, or send messages as your business. They must not appear inside pages or files delivered to visitors, even when those values are difficult to notice.

Developers call a password, payment key, or access code with this power a secret. The safe arrangement is to keep it in a protected setting used only by the computer that performs the work. Developers call that computer-side area the server side. Your AI builder may manage these protected settings for you. Ask it to explain where each item is held and confirm that visitors receive only the result of the work, never the password, key, or code itself.

If one of these items was ever available in a downloadable file, hiding or deleting the file is not enough. Someone may already have copied it. Disable the exposed item in the provider's official account panel, create a replacement, place the replacement in the protected setting, and check that the app still works. Also review activity records offered by the provider and follow any notice duties that apply to affected customers.

Repeat the review after adding uploads, downloads, reports, team screens, account changes, or AI-generated features. Keep two test accounts and several harmless files so the same checks are easy to repeat. Record the date, the feature changed, the expected results, the actual results, and who reviewed them. A short, repeatable check is more useful than a long review that happens only once.

The technical name for repeated checks that look for important changes over time is monitoring. VibeCodeWall checks the public app from the outside, as a visitor would, and watches for important changes over time. It does not inspect the hidden project files used to build your app. Its outside checks can complement, but cannot replace, your own signed-in tests of which customer and team accounts may use each saved file.

When a test fails, pause the affected file feature if you can do so safely, correct the rule, and repeat every related test. If real customer information may have been public, preserve enough records to understand what happened without spreading the information further. Follow the notice and reporting duties that apply to your business. Replace any password, payment key, or access code that may have been included, and document the final result.