Let Customers Send Files Without Exposing Their Information

A button for sending files lets customers place photos or documents into your app. That may be useful for profile pictures, receipts, identity documents, or support requests. It also means someone can try to send something the app was never designed to handle. Begin with a short written list of what the feature genuinely needs. A receipt field might accept JPG, PNG, and PDF files, while a profile-picture field might need only JPG and PNG images.

Do not trust only the letters at the end of a filename. Someone can rename an unrelated file from item.exe to receipt.pdf without changing what is inside it. Your app should inspect the file’s stated kind and its actual contents before saving it. The technical name is file type validation. For images, ask the app to confirm that the file can really be read as an image. For a PDF, ask it to confirm the expected PDF structure. Refuse mismatches and explain the accepted choices in ordinary language.

A phone photo, scanned document, or video can be much larger than it appears on screen. Without a maximum, one accidental choice or many repeated attempts can consume storage space, make customers wait, and increase your bill. Choose the smallest size that works with real examples. A profile photo usually needs much less room than a multi-page document. Use a separate limit for each purpose instead of allowing one very large size everywhere.

Show the maximum beside the file button so people know the rule before choosing anything. Check the size again in the computer service that receives and saves the file; developers call this server-side size validation. This second check matters because a visitor can sometimes bypass a rule shown only on the page. Reject an oversized file before permanent saving, remove any unfinished copy, and give a helpful message such as “This file is over 10 MB. Choose a smaller PDF.” Test files just below and just above every limit.

Your app has an area containing pages, logos, and other items that any visitor may receive. Customer uploads do not belong there. Save them in a separate place that is not open for public browsing. The technical name for that place is private storage. A person should receive a file only after the app has checked that the person is allowed to see it. Turning off a visible file list is not enough if someone can still guess an address and open the document directly.

Create a new, unpredictable saved name for every file instead of trusting the customer’s original name. Two people may both send receipt.pdf, and one file must never replace the other. An original name can also reveal customer information in records or addresses. Keep it only when the person needs to see it, and display it as ordinary text rather than instructions the app could follow. Passwords, payment keys, and access codes must never be written into downloadable files or file addresses. Record which account owns each saved file.

Imagine Ana and Ben are both signed in to your app. Ana should not be able to see, download, replace, or delete Ben’s receipt merely by changing a number in a web address. For every file action, the app must compare the current account with the owner recorded for that file. If staff members need access, give it only to clearly named work roles that require it. The technical name for deciding what a signed-in person may do is authorization.

Make this decision in the computer service that handles the request, not only by hiding buttons on the page. A hidden button can reduce confusion, but it does not prove that a person may open the file. For sensitive documents, avoid permanent addresses that keep working when copied. The technical name for a short-lived address is a signed URL. Create one only after the ownership check, make it expire quickly, and do not place customer information in it. Test every action with two ordinary accounts, not only an owner or staff account.

Keep a short repeatable test: send an allowed file, a disallowed file, a renamed file, an oversized file, and two files with the same name. Then use a second customer account to try viewing, downloading, replacing, and deleting the first account’s file. Copy a file address into a new private browsing window, which is a fresh visit without the original account’s sign-in, and confirm that it does not reveal the document. Record the result and remove test files when finished.

Repeat the test after changing a form, file storage, account roles, or download behavior. Ask your AI builder to explain in everyday language where every check happens, so you can notice if a new screen skips one. VibeCodeWall checks the public app from the outside and watches for important changes over time; it does not need access to private code. That outside check complements your account tests, but it cannot replace checks involving customer files that the public app cannot see.