Secure file uploads in an AI-generated app: type, size, ownership and retrieval

A worked example: where the task becomes difficult

A fictional customer portal accepts project reference images. The generated form allows any file and stores it under a public URL. A client may accidentally upload a private document, while a malicious caller can bypass the picker. Start with a narrow supported image workflow and controlled fixtures. Define whether the file is public, organization-private or available through restricted links.

Decisions to make before implementation

Set accepted formats, maximum size, naming policy and retention. Decide how content is validated and whether additional scanning or transformation is required for the threat model. Do not trust a filename extension as the only evidence of type. Avoid executing uploaded content. Record ownership so removing a user or project affects the intended retrieval permissions without deleting unrelated files.

A practical sequence for the work

Use the sequence below as a task boundary, not as a claim that the example has been executed. Work with approved inputs and the project’s actual architecture. If a required integration or permission is unavailable, keep that stage visibly incomplete rather than generating a plausible substitute result.

• Write the permitted file contract and storage visibility.
• Implement receiving checks and safe object naming with controlled fixtures.
• Authorize retrieval and deletion against the owning resource.
• Test invalid content, oversized files and interrupted uploads before launch.

A detailed brief you can adapt for your agent

Replace the illustrative context with your approved facts and controlled inputs. Keep the stated boundaries when adapting the brief. The expected deliverable matters more than a particular tool name: ask for an explanation grounded in the inspected material and evidence for the requested outcome.

Implement a restricted reference-image upload journey using the existing storage system. Define accepted formats, size, ownership and retrieval policy. Validate on the receiving side and avoid executing content. Use safe object identifiers, controlled invalid fixtures and an orphan-cleanup strategy. Do not claim scanning or expose storage authority without an actual configured mechanism.

Failure modes that an attractive preview can hide

A successful upload can leave an orphaned object if the record save fails. Plan cleanup and reconciliation. Avoid embedding raw uploaded markup into pages. Do not expose storage credentials to the browser as a shortcut. A file preview should communicate its actual processing state rather than claim the content has been scanned when no scanner is configured.

Technical references: MDN: File API · MDN: practical security implementation guides

Acceptance checks and the evidence to retain

Keep the upload contract, receiving checks, ownership enforcement and cleanup behavior. Document content-processing services that remain absent rather than implying protection from a checkbox.

Specific answers

Common questions