Questa pagina è disponibile solo in inglese.
File Uploads and Object Storage
Pathrule3 regole • 1 memoria • 1 skill
File uploads and object storage form an asynchronous trust boundary spanning authorization, transfer, validation, malware scanning, metadata, lifecycle, and download delivery. This bundle defines bounded upload intents, opaque keys, quarantine and publish states, safe content handling, and cleanup. Unlike REST API Design, it owns blob security and lifecycle rather than the general shape and semantics of HTTP resources.
Mappa dei percorsi suggerita
Pathrule colloca ogni elemento sul percorso corrispondente, così il tuo assistente lo vede solo dove serve. È l'ambito che ottieni con l'importazione; puoi modificarlo nel tuo workspace.
Regole
3Create a bounded upload intent before transfer/src/apialtavincolanteThe server authorizes owner, purpose, size, content class, object key, operation, and expiry before any client writes bytes.
| 1 | The server authorizes owner, purpose, size, content class, object key, operation, and expiry before any client writes bytes. A broad presigned request or shared storage credential lets clients choose arbitrary keys, overwrite objects, exceed quotas, or upload a type the product never intended to process. Enforce this boundary in /src/api so invalid work stops before it reaches another subsystem or creates an externally visible side effect. |
| 2 | |
| 3 | - Generate an opaque server-owned object key that includes no filename, email, tenant secret, or trusted path fragment from the client. |
| 4 | - Bind the upload authorization to one tenant, subject, purpose, object key, method, maximum size, allowed content class, and short expiry. |
| 5 | - Reserve quota and an upload record before transfer, then release it when the intent expires or validation fails. |
| 6 | - Use multipart upload only through a tracked session with bounded part count, total size, completion, abort, and cleanup behavior. |
| 7 | |
| 8 | Verification: Attempt key changes, method changes, oversized bodies, expired intents, cross-tenant reuse, duplicate completion, and abandoned multipart sessions; confirm storage and quota remain correct. |
Quarantine bytes until independent validation completes/src/uploadsaltavincolanteNew objects remain unavailable to users and processors until server-side type, structure, policy, and malware checks pass.
| 1 | New objects remain unavailable to users and processors until server-side type, structure, policy, and malware checks pass. Filename extensions, Content-Type headers, and browser previews are attacker-controlled hints and cannot establish that content is safe to serve or parse. Enforce this boundary in /src/uploads so invalid work stops before it reaches another subsystem or creates an externally visible side effect. |
| 2 | |
| 3 | - Read the stored bytes from quarantine and validate signature, parseability, declared class, size, decompression limits, and product-specific structure. |
| 4 | - Run malware or content-disarm controls appropriate to the allowed type without sending sensitive files to an unapproved external scanner. |
| 5 | - Process risky formats in an isolated, resource-bounded worker with no ambient credentials or unnecessary network access. |
| 6 | - Publish by changing durable application state or copying to a delivery boundary only after every required check succeeds. |
| 7 | |
| 8 | Verification: Upload polyglots, mismatched extensions and signatures, malformed archives, decompression bombs, scanner timeout, and clean fixtures; confirm only clean objects become addressable. |
Memorie
1An upload is a two-phase resource/src/uploadsObject storage can contain bytes before the application has validated, accepted, or made them visible, so existence is not completion.
| 1 | Object storage can contain bytes before the application has validated, accepted, or made them visible, so existence is not completion. Track intent-created, transferring, uploaded, validating, ready, rejected, expired, and deleted states with idempotent transitions. |
| 2 | |
| 3 | Keep object events as evidence that may trigger validation, not proof that the intended principal completed the intended upload. Reconcile records and storage when events are missing, duplicated, or reordered. Expose only ready objects to product queries and schedule cleanup for every terminal non-ready state. Keep the decision explicit at /src/uploads; moving it into an incidental caller makes behavior depend on which route happened to execute first. |
| 4 | |
| 5 | See /src/jobs for reconciliation and scanning and /src/api for download authorization. That related boundary consumes this decision and carries the evidence that proves it still holds. |
Skill
1test-file-upload-pipeline/rootTest file uploads across authorization, transfer, validation, scanning, publication, delivery, and cleanup failure paths.
| 1 | --- |
| 2 | name: test-file-upload-pipeline |
| 3 | description: Test file uploads across authorization, transfer, validation, scanning, publication, delivery, and cleanup failure paths. |
| 4 | --- |
| 5 | |
| 6 | # Test File Upload Pipeline |
| 7 | |
| 8 | Run this procedure whenever the governed surface changes or its operational evidence becomes stale. |
| 9 | |
| 10 | 1. Create clean, malformed, oversized, mislabeled, polyglot, active-content, archive-bomb, malware-test, duplicate-name, and zero-byte fixtures for every allowed class. |
| 11 | 2. Attempt cross-tenant keys, expired and replayed intents, changed methods, multipart abuse, concurrent completion, and quota races through the real storage integration. |
| 12 | 3. Inject storage, event, parser, scanner, worker, database, and publish failures before and after each durable transition, then replay events and jobs. |
| 13 | 4. Verify only ready objects are downloadable, active content is isolated, rejected and abandoned bytes expire, quotas reconcile, and audit events reveal no secret URL or personal filename. |
| 14 | |
| 15 | Record the decision, failed checks, and follow-up owner with the change. A successful run leaves reproducible evidence that another reviewer can inspect without repeating the investigation from memory. |
Perché questo pattern
Agents trust filenames and MIME headers, publish objects before scanning, put user names into storage keys, or issue broad presigned URLs with no ownership or lifecycle state.
Pensato per: Backend teams accepting user files into cloud or self-hosted object storage.
Aiuta il tuo assistente a evitare:
- Executable or deceptive content published from client-declared metadata
- Cross-tenant overwrite or download through predictable object keys
- Abandoned multipart uploads and quarantined objects retained forever
- Licenza
- Apache-2.0
- Versione
- 1.0.0
- Aggiornato
- 2026-08-25