Let Customers Send Files Without Exposing Their Information
A file button can expose customer information or overwhelm your app when its rules are too loose. Use this checklist to accept only what you need and keep each file protected.
before you start
Before accepting a photo, receipt, or document, decide what is allowed, how large it may be, where it will stay, and who may open it.
Accept only the files the app needs
in plain words
Each file button should accept only the few kinds of photos or documents required for its purpose.
Start with the job the customer is trying to finish. A profile picture field may need common photo files, while an expense form may need receipt photos and PDF documents. Write a separate allowed list for every file button. Show that list before the customer makes a choice. Broad rules such as “all files” are convenient during setup, but they let the app receive material your team cannot use, review, or safely keep.
A name ending in .jpg or .pdf does not prove what a file contains because anyone can rename a file. The app should examine the file itself before saving it and compare the result with the allowed list. The technical name is file type validation. One useful check compares the file's internal description, which developers call its MIME type, with its actual content. If they do not agree, the app should refuse the file and explain which kinds are accepted.
- ▸Create a separate allowed list for every file button.
- ▸Display accepted kinds before the customer chooses a file.
- ▸Check the file itself before saving it.
- ▸Use a clear refusal message that tells the customer what to choose instead.
common risk
A receipt field checks only whether the name ends in .jpg. Someone renames an unrelated file to look like a photo, and the app saves it without checking what it really contains.
what to do now
Open every file button in your app and write down its purpose and allowed file kinds. Remove any kind that is not necessary for that purpose.
ask your AI
Review every file upload in this app. For each one, list its purpose and allow only the file types needed for that purpose. When the protected part of the app receives a file, check its actual content and MIME type before saving it; do not trust only the filename or the browser's description. Refuse mismatches and show a friendly message listing the accepted types. Do not change unrelated features.
Stop files that are too large
in plain words
A maximum size prevents one upload from consuming more storage, time, or money than the app can handle.
A phone photo, scanned document, or video can be far larger than the customer realizes. Without a maximum, one accidental upload may slow the app, consume paid storage, or keep other work waiting. Choose a limit that matches each purpose instead of applying one unexplained number everywhere. A profile picture normally needs less space than a multipage document. Show the maximum beside the file button so customers can choose correctly before waiting for an upload.
The app can warn the customer immediately, but it must also repeat the check in the protected part that receives the file. A page shown to visitors can be changed or bypassed. The technical name for the protected receiving computer is the server, and developers call the rule a file size limit. Refuse the file before storing or processing it. Give a useful message with the exact maximum, and do not silently shrink, convert, or discard an important document without explaining the change.
- ▸Choose a maximum that fits each upload purpose.
- ▸Show the maximum beside the file button.
- ▸Repeat the size check where the app receives the file.
- ▸Refuse oversized files before storing or processing them.
common risk
A feedback form has no maximum size. A customer accidentally selects a long video, leaving the app to store and process a file the team never needed.
what to do now
Test every file button with one file just below its maximum and another just above it. Confirm that only the first is accepted and that the refusal explains what to do.
ask your AI
Add a specific maximum file size to every upload in this app based on its purpose. Show the maximum beside the file button. Check it both before sending and again on the server before any storage or processing. Refuse oversized files with a message that states the exact limit and asks the customer to choose a smaller file. Do not silently alter important documents.
Keep saved files away from public pages
in plain words
Customer photos and documents should stay in a protected storage area rather than beside files that every visitor can download.
Files used to display the app's logo and page images are normally available to every visitor. Customer receipts, identity documents, and profile photos do not belong in that same place. Save them in an area that does not provide a permanent public address. Keep a separate record connecting each file to its owner and purpose. Give every saved file a new, unpredictable name created by the app, while preserving the original name only as information when it is genuinely useful.
Developers call this private object storage. The app should check the person first and then create a download address that stops working soon. The technical name is a signed URL. A difficult-to-guess name adds protection against casual guessing, but it does not replace the identity and permission check. Passwords, payment keys, and access codes that can reveal customer information or spend money must remain in the protected part of the app and must never be included in pages or files delivered to visitors.
- ▸Use a storage area without permanent public addresses.
- ▸Create a new unpredictable name for every saved file.
- ▸Connect each file record to its owner and purpose.
- ▸Keep passwords, payment keys, and access codes away from visitor-delivered files.
common risk
The app saves invoices in the same public folder as its logo. Anyone who receives or discovers an invoice address can open it without identifying themselves.
what to do now
Ask your AI builder where customer files are stored. Copy the address of a test file into a signed-out or private browsing window and confirm that the file does not appear.
ask your AI
Move every customer-uploaded file into non-public object storage. Create a new unpredictable saved name, and record the owner, purpose, original display name, upload time, and storage location. Never expose a permanent public file address. Keep storage passwords, payment keys, and access codes only in the protected server environment. After checking permission, provide a short-lived signed URL for an allowed download.
Check every person before showing or changing a file
in plain words
Signing in is only the first step; the app must also confirm that the person may use that particular file.
A signed-in customer should not automatically see every customer file. Before opening, downloading, replacing, or deleting one, the app must compare the person making the request with the file's owner and purpose. Team members should receive only what their work requires. Someone reviewing a claim may need its attachment, while someone editing marketing text does not. Apply the same decision to every file action, including less obvious actions such as previews and replacement attempts.
The technical name for this decision is authorization. It must happen in the protected part of the app every time, not only by hiding a button on the page. A hidden button changes what someone sees but does not control what the app accepts. Record important file actions so you can investigate mistakes. The technical name is an audit log. Test with two normal customer accounts and a limited staff account instead of relying only on the app owner's powerful account.
- ▸Check the file owner and purpose before every action.
- ▸Give each staff role only the access required for its work.
- ▸Apply checks to previews, downloads, replacements, and deletions.
- ▸Test with ordinary accounts that have different permissions.
common risk
The customer page hides other people's attachments, but the file request itself does not check ownership. A signed-in customer can ask the app for another customer's receipt.
what to do now
Create two ordinary test customers. Upload a file with the first account, then confirm that the second cannot preview, download, replace, or delete it.
ask your AI
Review every action involving an uploaded file: preview, view, download, replace, and delete. On the server, verify the signed-in person's identity and permission for that specific file every time. Check ownership, file purpose, and staff role. Do not rely on hidden buttons or page-only checks. Add an audit log for allowed and refused file actions without recording file contents, passwords, payment keys, or access codes.
Remove old files and keep checking for changes
in plain words
Files should not remain forever by default, and their protections should be retested whenever the app changes.
Keeping every upload forever increases the amount of customer information that could be exposed by a future mistake. Decide how long each kind of file is needed for customer service, business records, or a legal duty. Tell customers when appropriate. After that period, remove both the saved file and its related temporary copies. Developers call this a retention policy. Include a careful process for requests to delete information, while preserving anything you are legally required to keep.
Repeat the tests after changes to forms, storage settings, staff roles, or file viewing. Automated checks can catch some regressions, which are old problems that return after a change, but a person should still review the rules and unusual cases. VibeCodeWall checks the public app from the outside and watches for important changes over time. It does not inspect protected code or prove that stored files are safe, so combine outside monitoring with checks requested from your AI builder.
- ▸Choose a keeping period for every file purpose.
- ▸Remove expired files and temporary copies.
- ▸Repeat upload and permission tests after important changes.
- ▸Use outside monitoring together with checks inside the app.
common risk
A temporary application form is removed, but years of identity documents remain in storage because nobody defined when they should be deleted.
what to do now
Make a list of stored file categories, why each is kept, and when it should be removed. Schedule a recurring review and rerun the account tests after important app changes.
ask your AI
Create a retention plan for every category of uploaded file in this app. Record why it is kept, how long it should remain, and any legal hold that prevents deletion. Add a scheduled process that removes expired files and temporary copies, records the result without storing file contents, and safely retries failures. Add automated tests for allowed types, wrong types, oversized files, ownership checks, expired download addresses, and deletion. Run these tests after changes to uploads, storage, or user roles.
Quick checklist
- 01List the exact file kinds needed by each file button.
- 02Check what a file really contains instead of trusting its name.
- 03Refuse every unneeded file kind before saving it.
- 04Set and display a maximum size for each kind of upload.
- 05Give every saved file a new name created by the app.
- 06Keep customer files away from pages and images available to every visitor.
- 07Keep passwords, payment keys, and access codes away from files sent to visitors.
- 08Check the person's identity and permission before every file action.
- 09Test with an allowed file, a disguised file, an oversized file, and two customer accounts.
- 10Delete files when their stated purpose and required keeping period end.
FAQ
Can I accept every file kind and inspect it later?
No. Accept only the kinds required for the task, check each file before saving it, and consider an additional harmful-file scan when the app handles documents from people you do not know.
Is changing the saved filename enough?
No. A new unpredictable name discourages guessing, but protected storage and a fresh permission check are what prevent the wrong person from opening the file.
Should customer files stay forever?
Usually not. Set a keeping period based on the file's purpose and any legal requirement, then remove the file and temporary copies when that period ends.
Can VibeCodeWall check these protections?
VibeCodeWall checks the public app from the outside and watches for important changes over time. It cannot inspect protected code or stored files, so also ask your AI builder to test the checks performed inside the app.