Control Packs · INP-002 · v1.0.0
Uploaded File and Document Handling
Decide which file types and sizes you accept, store them under a name and location the uploader does not control, and never serve or open one in a way that lets its content or name reach somewhere it should not.
Status: review · Review: not independent. This is design guidance; review status does not establish independent verification or compliance.
What this safeguard addresses
Ensure supplied files have a confirmed accepted set of types and sizes, are stored under a system-controlled name and location outside any path that executes code, are bounded when parsed, and are only ever returned to a party entitled to them.
- A file someone else chose is treated like a file you wroteAn uploaded document, image, or archive is stored under a name the uploader controls, served from a path that also serves code, opened by a parser with no size or depth bound, or handed to another user without a check.
Versioned applicability rule
{
"characteristic": "UNTRUSTED_INPUT",
"equals": true
}Decisions for the project owner
Leave a decision open when its value is unknown. Suggested values become confirmed only through an explicit user decision.
- Which file types and sizes do you accept, and who may download them afterwards?An accept-anything upload is the easiest thing to build and the hardest to bound later. The types, the size, and who may read the file back are all yours to state.INP-002-Q1 · scope
Requirements for the coding agent
- INP-002-R1Accept only the confirmed file types and sizes, verify type by content rather than by extension alone, store each file under a system-generated name and location outside any path that serves or executes application code, bound the size and nesting depth of anything parsed or expanded, and authorize every download against the confirmed audience.
Tests and evidence to retain
- FILE_HANDLING_TESTUpload a file whose extension disagrees with its content, a name containing path separators, an archive that expands far beyond its compressed size, and an oversize file, and confirm each is refused; then attempt to download another party's file and confirm denial.
- configuration_or_policy
- implementation_location
- test_result
- telemetry_definition
Passing a published example shows that example's behavior. A coding agent's implementation report remains a claim until its evidence is independently checked.
Related guidance
- SI-3 · Malicious Code ProtectionNIST_SP_800_53_5_2_0 · informsConstraining accepted types and storing files outside executable paths reduces one avenue for malicious content; it is not malicious-code protection on its own.
- SI-10 · Information Input ValidationNIST_SP_800_53_5_2_0 · partially addressesVerifying type by content and bounding size is input validation for the upload path; it does not cover the full control family.
- SC-5 · Denial-of-Service ProtectionNIST_SP_800_53_5_2_0 · informsBounding parse size and expansion depth limits one avenue of resource exhaustion; it is not a denial-of-service strategy.
Mappings indicate contextual relevance or partial support. They do not establish equivalence, certification, government endorsement, or complete framework implementation.
- National Institute of Standards and Technology — Security and Privacy Controls for Information Systems and OrganizationsGUIDANCE_NIST_SP_800_53_5_2_0
- OWASP Cheat Sheet Series — LLM Prompt Injection Prevention Cheat SheetGUIDANCE_AI_CONTENT_BOUNDARY