Let People Upload Files Without Exposing Their Information
An upload button needs rules. Use this beginner-friendly checklist to accept only the files you need, limit their size, store them safely, and keep customer documents from public view.
before you start
Before customers attach photos or documents, decide what your app will accept, where it will keep each file, and who may open it.
Decide exactly what people may send
in plain words
Each upload button should accept only the file kinds needed for its particular job.
Start with the task shown on the screen. A profile picture usually needs an image. An expense claim may need an image or PDF document. A job application may need a PDF document. If that task has no reason to receive videos, spreadsheets, compressed folders, or files that run instructions, your app should refuse them. Write the accepted choices beside every upload button so customers know what to select.
This matters because accepting everything makes your app responsible for files it was never designed to display, store, or share. The simple rule is to name the small set of acceptable file kinds and reject everything else. The technical name is an allowlist. Apply it separately to every place that receives files, including customer forms, support messages, staff screens, and less obvious attachment buttons.
- ▸List every place where a person can attach a file.
- ▸Write the exact file kinds needed at each place.
common risk
A support form accepts every file kind, so it receives a file that the app cannot safely display or that the team never intended to keep.
what to do now
Make an upload inventory and remove every accepted file kind that has no clear purpose.
ask your AI
Review every place where this app accepts an uploaded file, including customer, support, and staff screens. For each place, state its purpose, allow only the image or document formats needed for that purpose, reject every other format, and show a clear message listing what the person may upload. Give me a final table of every upload location and its allowed formats.
Stop files that are too large
in plain words
Set a size that suits each task so one attachment cannot slow the app or consume unexpected storage.
A phone photo can be much larger than it looks on the screen. Several large attachments can make a form feel stuck, raise storage costs, or leave an unfinished upload behind. Pick a maximum that matches the job instead of using one generous number everywhere. A profile picture can have a smaller maximum than a scanned contract. Show the maximum before the customer chooses a file and give a useful refusal message.
The final size decision must happen in the protected part of the app that the visitor cannot change. Developers call this server-side validation. A check in the visitor's browser is useful because it gives quick feedback, but it is only an early warning. Confirm the size again when the app receives the file. Also remove partial files when an upload fails, or they may quietly continue using storage.
- ▸Choose and document a maximum size for each upload purpose.
- ▸Test a file just below and another just above every maximum.
common risk
A customer selects several enormous photos, the form appears frozen, and incomplete copies remain stored even though the request fails.
what to do now
Set a separate maximum for each upload task and make the protected part of the app enforce it.
ask your AI
Add a documented maximum file size to every upload in this app. Show each maximum before file selection, check it again in the protected server processing after the file arrives, reject oversized files with a friendly message, and delete partial or rejected copies. Create tests using files just below and just above every maximum.
Check the file itself before saving it
in plain words
A familiar filename does not prove that the received file is really a photo or document.
A person can rename almost any file to holiday.jpg or receipt.pdf. Your app should first read enough of the received file to confirm that its real format matches an allowed choice. The technical name is file-type validation. The label reported by the person's device can help, but it must not be the only evidence. If the checks disagree, refuse the upload and explain which formats are accepted.
After accepting a file, create a new unpredictable name for the saved copy. Keep the customer's original name only as text to display when useful. This prevents two files called receipt.pdf from replacing or being confused with each other. It also prevents unusual characters in a name from being treated as app instructions. Never open an uploaded file as a program or instruction merely because its name looks acceptable.
- ▸Compare the file's real format with the allowed choices.
- ▸Create a unique app-made storage name for every accepted file.
common risk
Two customers upload receipt.pdf, and weak naming rules cause one attachment to replace or become confused with the other.
what to do now
Verify the received format, refuse mismatches, and rename every accepted file before saving it.
ask your AI
Improve every upload so the app verifies the received file's real format instead of trusting only its name or the label supplied by the device. Compare the result with the allowed formats, reject any disagreement, save accepted files under unique unpredictable app-created names, and keep the original filename only as safely displayed text.
Keep customer documents away from public view
in plain words
A customer file should remain hidden unless the right person is asking for that particular file.
Receipts, identity documents, medical notes, contracts, and personal photos can contain customer information. Keep them in a location that does not open merely because someone knows or guesses an address. The technical name is private storage. Public sharing should be a deliberate exception for a feature that truly requires it, not the default for every attachment.
Before showing or downloading a file, the app must identify the person and confirm that the person may open that exact record. The technical name for this second decision is authorization. Signing in only establishes which account is present; it does not mean that account may open every customer's files. Staff access should also be limited to people whose work requires it. If temporary sharing is necessary, make the shared address expire and avoid revealing the permanent storage location.
Passwords, payment keys, and access codes that can open customer information or spend money do not belong in uploaded documents, public storage, or files delivered to visitors. Keep them only in the protected settings supplied by your app platform. Uploaded customer information should also have a retention rule: decide when old files are no longer needed and remove them through a controlled process.
- ▸Use private storage for customer attachments by default.
- ▸Confirm permission for the exact file before every view or download.
- ▸Decide when old customer files should be removed.
common risk
A receipt is placed in a public folder, and anyone who receives its address can open the customer's information without signing in.
what to do now
Make existing and future customer uploads private, then test every way a file can be viewed, downloaded, or shared.
ask your AI
Make all existing and future customer uploads private by default. Before every preview, view, download, or share, identify the signed-in account and confirm it may use that specific file; customers must reach only their own files. Limit staff access by job need, make temporary sharing addresses expire, and keep passwords, payment keys, and access codes outside uploaded or visitor-downloadable files. Report any currently public customer files without deleting them.
Test now and keep checking after changes
in plain words
Simple repeatable tests show whether the rules still work in the version customers actually use.
Use a test account to upload an accepted file. Then try a wrong file kind, a file just over the maximum, and a renamed file whose contents do not match its name. Confirm that each refusal is clear, no usable attachment record remains, and no rejected or partial copy can be opened later. Try the same actions on every upload screen, because one forgotten form can behave differently.
Next, create a second test customer. Upload a file with the first account, then confirm that the second account cannot preview, download, replace, or delete it. Also check that a customer cannot change a file number or copied address to reach someone else's attachment. Repeat this checklist whenever you change uploading, sign-in, storage, staff permissions, or sharing.
VibeCodeWall checks the public app from the outside and watches for important changes over time. It does not need to see private code to help notice information that has become publicly reachable. Outside monitoring complements your own account-based tests; it cannot decide every business rule about which customer or staff member should see a particular document. Keep the checklist and rerun it after every important change.
- ▸Test accepted, oversized, mismatched, renamed, and interrupted uploads.
- ▸Use two accounts to test separation between customers.
- ▸Repeat the checklist after every important upload or sharing change.
common risk
The form displays a refusal, but a rejected file remains saved and later becomes reachable from another screen.
what to do now
Run the complete checklist in the public app now and schedule it again after every relevant change.
ask your AI
Create and run a safe test plan for every file upload in this app. Cover an accepted file, a disallowed format, a file just over the maximum, contents that do not match the filename, duplicate filenames, an interrupted upload, and cleanup of every rejection. Use two test customer accounts to prove that neither can preview, download, replace, or delete the other's files. Do not use real customer information, passwords, payment keys, or access codes. Summarize each result and the exact fixes still needed.
Quick checklist
- 01Accept only the file kinds required for each task.
- 02Set a maximum size for every upload.
- 03Check what the received file really is, not only what its name says.
- 04Give every saved file a new name created by the app.
- 05Keep customer files away from public pages by default.
- 06Check the person and the specific file before allowing viewing or downloading.
- 07Remove rejected and incomplete uploads.
- 08Test with two customer accounts before inviting real customers.
- 09Repeat the tests after important changes.
- 10Keep passwords, payment keys, and access codes out of uploaded files and publicly downloadable app files.
FAQ
Should every customer upload be hidden from the public?
Usually yes. Keep it hidden by default when it belongs to a customer or contains personal information. Make it public only when public sharing is the clear purpose and the customer understands that choice.
Is checking the end of a filename enough?
No. A file can be renamed. The app should also examine the received file and confirm that its real format is one of the allowed choices.
Does signing in let a customer open every file?
No. After identifying the account, the app must still confirm that the account may open that particular file.
What should happen to a refused upload?
The person should receive a clear explanation, and the app should remove partial copies and avoid creating a usable attachment record.