16. File Upload and Content Security #
16.1 Purpose and scope #
This section governs any feature that accepts user‑supplied content (e.g., baggage photos, documents) via web, mobile, API, email ingestion, or batch imports. Controls apply from receipt through scanning, storage, access, and deletion.
16.2 Content acceptance rules #
Only explicitly approved content types may be accepted; server‑side validation must verify MIME type and magic bytes, not just file extensions. Requests that violate type or size limits must be rejected with a generic error and logged. PENDING: Allowed MIME types list; maximum file size per item __ MB; total per claim/session limit __ MB
16.3 Malware scanning and disposition #
All uploads must be scanned by an AV/antimalware engine before further processing or storage. Scanning must occur server‑side, with signature updates applied automatically. If malware is detected, the file must not be made available to users or downstream systems; it must be quarantined and an alert raised. Define the user‑facing behavior (block vs notify) and administrative workflow. PENDING: AV action — Block outright / Quarantine + notify; notification targets; user messaging pattern
16.4 Metadata and privacy hygiene #
Images and similar media must have sensitive metadata (e.g., EXIF, GPS coordinates, device identifiers) stripped on ingest unless such metadata is explicitly required for a documented business purpose. If retained, metadata must be treated as Restricted Data and disclosed in the data flow and privacy documentation. PENDING: EXIF/GPS stripping rule — Required/Not required; any exceptions
16.5 Storage protection and lifecycle #
Uploaded content must be stored encrypted at rest using strong algorithms, with keys managed in a vault/KMS and segregated per environment. Access to content must be authorized on every retrieval (no guessable URLs; signed and time‑limited access URLs where applicable). Retention periods must follow business requirements with the ability to purge content early if required by privacy obligations (e.g., subject deletion), using crypto‑shred or verified deletion from all tiers and replicas. PENDING: Business retention for photos/docs; crypto‑shred requirement confirmation
16.6 Transformation and processing #
Any transformations (thumbnailing, format conversion, OCR) must operate on scanned content only and must not write unscanned derivatives to persistent storage. Derived artifacts inherit the same classification and retention policies as the source. Processing jobs must run with least‑privilege service identities and write to approved locations only.
16.7 Access patterns and safeguarding #
User interfaces must prevent inline execution of content and enforce content‑security policies to avoid XSS via uploaded files. For document viewing, prefer safe renderers or conversion to a neutral format (e.g., PDF/A or image) before display. Download endpoints must enforce authorization checks per request and emit audit logs (who/when/what). Links for external recipients must be signed, time‑limited, and minimally permissive (view‑only by default).
16.8 Logging and audit #
Log upload attempts (success/failure), file metadata (name/type/size), AV scan result, uploader identity, disposition (accepted/quarantined/rejected), and retrieval events, including the accessor and outcome. Redact or hash any sensitive filename segments where necessary. Ensure logs meet the SIEM field baseline (who/when/where/what/outcome/correlation ID) and retention targets. PENDING: Retention months and SIEM forwarding decision/method
16.9 Abuse controls and rate‑limiting #
Apply per‑user and per‑IP limits on upload frequency and aggregate size to deter abuse. Enforce conservative server‑side request size caps and timeouts. Detect and block repeated malware submissions, malformed content, or suspicious patterns with WAF/IDS rules and application‑level throttling. PENDING: Default rate limits and caps
16.10 Mobile and edge capture (if applicable) #
When uploads originate from mobile or field devices, the app must encrypt content at rest on the device, use secure transport, and purge local copies immediately after confirmed server‑side acceptance (or within a short, enforced window if offline capture is supported). MDM‑enforced devices may be permitted for temporary storage subject to encryption and auto‑purge policies. PENDING: Local retention window (e.g., purge within __ hours); whether MDM is required for staff devices
16.11 Email ingestion (if applicable) #
If content can be submitted via email, use dedicated ingestion mailboxes with strict allowlists, AV scanning before processing, and quarantine of suspicious attachments. Strip active content (macros/scripts) from office documents unless explicitly needed, and treat the sender address as untrusted input with validation against case context. [If not used, mark N/A]
16.12 Exceptions #
Any deviation (e.g., temporarily accepting an additional file type for a pilot) requires a documented exception with scope, rationale, risk assessment, compensating controls (e.g., heightened scanning, manual review), owner, approval (ISO and Executive Sponsor), and expiry.