Files, uploads, and path boundaries

A file is more than a filename. The application may store it, extract it, parse it, generate a preview, and deliver it to another user. Each operation introduces a different security decision.

Separate the failure classes

Traversal escapes an intended path boundary. Inclusion loads a file through a runtime mechanism that may interpret code. An ordinary download reads data; it is not automatically code inclusion. Uploads can create unauthorized disclosure, overwrites, harmful processing, or resource exhaustion even when nothing executes.

Using a user-provided filename is not automatically a vulnerability. The question is whether the design treats it as display metadata or allows it to choose a sensitive filesystem object.

Paths are structured objects

A raw string prefix comparison does not prove that a resolved path remains inside an allowed directory. Adjacent names can share a prefix without sharing a directory. Symbolic links and concurrent filesystem changes can also invalidate a prior check.

Prefer application-controlled identifiers mapped to approved objects. Where paths are necessary, use platform-aware, component-based containment checks and filesystem APIs that preserve confinement during the actual operation. Archive entries, link targets, and extraction sizes need equivalent consideration. Linux openat2 documentation illustrates why resolution controls belong to the filesystem operation.

Scenario: the homework portal

The portal generates storage names, stores documents outside executable web content, and retains the student’s original name only as metadata. A preview worker receives limited access and resource limits. Downloads pass through an object-level permission check.

The random storage name reduces accidental collisions and discovery, but does not authorize access. A classmate who learns the name must still be denied. Deleting executable permission bits also does not stop an interpreter from reading a file as code; runtime configuration matters.

Validate the content and its consumers

Extensions, declared MIME types, and file signatures are useful signals, not complete proof of safe content. Use an allow-list appropriate to the feature, maintained parsers, limits, and isolation. Malware scanning can reduce risk without guaranteeing that every accepted file is harmless.

Serve untrusted content with intentional content types and disposition. Consider a separate content origin that does not receive application credentials. Keep sensitive download authorization regardless of storage location.

Evidence for a useful review

Document the accepted types, storage mapping, overwrite policy, processing permissions, extraction rules, delivery origin, and authorized audience. Review these together: safe storage cannot compensate for an unrestricted download endpoint, and a safe filename cannot repair a vulnerable parser.

Follow one document through its lifecycle

The fictional homework portal defines three states: quarantined, approved, and deleted. Students may download only their own approved documents; a teacher may read approved documents for their current class. A preview is a separate derived object that inherits the document’s audience.

The owner supplies these records: F1 is an approved version of Jo’s document. F2 is its preview, stored under a random identifier. F3 is a replacement document version awaiting review. The portal checks approval and the permitted audience for original downloads, but its preview route checks only that the random identifier exists.

PredictDoes the original download’s permission check establish that F2 is correctly protected?

F2 has its own delivery path. Its random identifier selects an object without proving the caller’s relationship to it. The preview route must apply the approved audience, including current class membership where relevant.

Approval also belongs to particular content. A scan result for F1 does not approve F3’s different bytes. Keep an unambiguous relationship between content version, processing results, release state, and derived previews. Otherwise an old result can be mistakenly used to release new content.

Separating upload, processing, and delivery makes the requirements easier to reason about. Acceptance can check permitted types and size; processing can use limited authority and resources; delivery can enforce the current object’s audience. A file that parses successfully can still be confidential, and a correctly authorized download can still contain content that should never have been released.

For deletion, define what happens to originals, previews, temporary files, and retained copies. A removed database row does not alone establish that every copy disappeared. Verification should follow the documented retention policy and identify any delayed removal, without collecting learners’ real files.