Threat Tribunal

Safe File Uploads, System Connections and Outputs

People outside the system can control filenames, file contents and metadata. Each processing step must check them because a file that passes one check can still be dangerous at the next.

  • Verify actual file content instead of trusting the supplied extension or reported file type.
  • Limit file size, expanded size, page count, processing time and cost before expensive work begins.
  • Build storage paths in a fixed, safe form and never use a filename to decide which customer may access a file.
  • Check AI output before displaying it, searching with it, writing it to a file or calling a privileged API.
  • Return useful errors without exposing implementation details, credentials, personally identifiable information (PII) or document content.

Fictional Security Examples

Illustrative File and Output Handling Examples

Illustrative only - not an engagement finding

Unsafe Uploaded Files Can Run in a Staff Member's Browser

Critical See where this finding applies on the diagrams: browser-to-API-to-storage path · CP1 public ingress
Business summary
When a staff member previews an uploaded file, the browser may treat code inside that file as part of the staff application. That code could read information shown to the reviewer, call the API through the reviewer's signed-in session or steal a browser access token. An uploaded document must never receive the same browser access as the application.
Assessment profile
Ease of attack
A normal-looking file hides executable contentAn attacker gives active content an allowed filename or reported file type, then relies on the preview to open it in the staff application.
Impact
The file acts through the reviewer's session
  • Code in the file could read page data or call APIs as the signed-in reviewer.
  • It could steal a Microsoft Entra ID access token if page scripts can read it.
Detection difficulty
Open a deliberately hostile test fileCheck what the server detects, how Blob Storage delivers the file, where React opens it and whether its code can reach the page, API or sign-in token.
Pattern
Treat the preview as an untrusted siteOpen uploaded files separately so code inside them cannot inherit the staff application's web address, permissions or signed-in session.
Expected fix Verification
  1. Expected fix Check what the file really contains FastAPI upload checks and background worker: Inspect the file's bytes and structure instead of trusting its name or the type reported by the uploader.
    Verification Reject files disguised by name or type A file containing active content is rejected or forced to download even when it uses an allowed filename or reported type.
  2. Expected fix Preview only formats that cannot run code FastAPI preview rules: Display only specifically approved non-executable formats. Force every unknown or active format to download instead.
    Verification Keep safe previews working Approved documents display correctly, while unknown or executable formats cannot run in the browser.
  3. Expected fix Open previews in an isolated browser area React preview and Blob Storage delivery: Use a separate web address or a restricted frame that cannot run scripts as part of the staff application.
    Verification Keep the file separate from the application Code in the preview cannot read the staff page, call its authenticated APIs or communicate through unrestricted scripts.
  4. Expected fix Tell the browser exactly how to handle the file FastAPI or Blob Storage response: Send the approved file type, display-or-download instruction, nosniff setting and content security policy.
    Verification Confirm every browser restriction The file response contains the required type, display-or-download instruction, nosniff setting and content security policy.
  5. Expected fix Keep sign-in tokens away from page scripts React and Microsoft authentication-library session handling: Store Entra ID tokens where code inside a preview or injected into the page cannot read them.
    Verification Confirm the preview cannot steal a token Hostile test content cannot read token storage or obtain the staff member's access token.

Related illustrative findings: document conversion limits; PII and processing context.

Illustrative only - not an engagement finding

One Uploaded File Can Exhaust Processing Capacity

High See where this finding applies on the diagrams: application zone · conversion under budgets step
Business summary
A file can look small when uploaded but require enormous work after it is opened. A compressed file may expand many times, a spreadsheet may contain millions of cells, or a PDF may contain thousands of pages. If the application does not stop that work early, one upload can fill worker memory, block the processing queue and trigger paid AI calls, delaying other users and increasing the cloud bill.
Assessment profile
Ease of attack
One deliberately expensive fileAn attacker uploads a compressed, page-heavy, image-heavy or very large spreadsheet file that requires far more work than its upload size suggests.
Impact
Other work stops and cloud costs rise
  • The file could consume the worker's memory, processing time or temporary storage.
  • Other customers' jobs could wait while repeated conversions and AI calls continue to incur charges.
Detection difficulty
Measure the work before paid services beginTest each supported file type and confirm that size, page, row, pixel, time and memory limits take effect before Document Intelligence or Azure OpenAI is called.
Pattern
Give every upload a hard processing allowanceEach file and processing step must have a maximum size, running time, memory use, temporary storage use, retry count and paid-service cost.
Expected fix Verification
  1. Expected fix Set limits for each file type before conversion FastAPI upload checks and converter entry points: Permit only supported formats and enforce upload size, expanded size, page, row and pixel limits before conversion begins.
    Verification Reject files that exceed any limit Compressed bombs, oversized spreadsheets, page-heavy files, extreme-resolution images and files with missing size information all stop before expensive work begins.
  2. Expected fix Limit each job's time, memory and temporary storage Isolated background worker: Stop each conversion when it reaches its maximum running time, memory use or temporary disk space.
    Verification Stop work at the configured limit Slow, memory-heavy and storage-heavy conversions stop at the approved worker limits.
  3. Expected fix Limit how many jobs and retries one customer can create Queue Storage scheduling and worker retries: Cap simultaneous conversions, retry attempts and total queued work for each customer and job.
    Verification Stop excess jobs and retries Simultaneous jobs, repeated retries and total queued work stop at the configured customer and job limits.
  4. Expected fix Do not call paid AI services after a limit is exceeded Worker check before Azure AI Document Intelligence and Azure OpenAI: Stop an over-limit job before it sends any paid analysis request.
    Verification Confirm rejected work creates no AI charge An over-limit job sends no request to Document Intelligence or Azure OpenAI.
  5. Expected fix Remove partial work without delaying other jobs Blob Storage, Cosmos DB and worker failure handling: Remove partial files and status records from a stopped job without blocking the API or unrelated work.
    Verification Confirm normal documents still complete A stopped job removes its partial files and records without delaying other jobs, while a normal document still completes.

Related illustrative findings: active document previews; reachable parser dependency.

Illustrative only - not an engagement finding

Error Messages Can Reveal PII and Internal Processing Details

Medium See where this finding applies on the diagrams: operations zone · telemetry and error paths · CP8 telemetry separation
Business summary
Error detail is valuable to engineers but can disclose filenames, record identifiers, model responses and internal structure to callers or broad log audiences.
Assessment profile
Ease of attack
Safe failure pathsA caller triggers malformed input or a provider error and inspects what the application returns or records.
Impact
PII and internal-detail disclosure
  • A caller or log reader could learn internal service details.
  • Errors could reveal PII, document, customer or model content.
Detection difficulty
Failure-path trace requiredExercise upload, conversion, Blob Storage, Document Intelligence and Azure OpenAI failures through responses, logs and Cosmos DB status.
Pattern
Error sanitizationPublic errors stay stable and minimal while protected diagnostics remain available to approved engineers.
Expected fix Verification
  1. Expected fix Use one public error contract FastAPI exception middleware: Return stable public error codes and a correlation identifier.
    Verification Return predictable failures Malformed requests and simulated provider failures return the approved code and correlation identifier.
  2. Expected fix Hide provider and stack details FastAPI adapters for Blob Storage, Azure AI Document Intelligence and Azure OpenAI: Never return raw provider errors, stack traces or internal hostnames to React.
    Verification Keep internal details private Browser responses contain no stack trace, internal hostname or raw provider error.
  3. Expected fix Fail without changing trusted state FastAPI authorization and Cosmos DB or Blob Storage failure handling: Prevent partial updates and hide whether an unauthorized resource exists.
    Verification Fail safely and preserve valid work An unauthorized request reveals no record existence, a failed operation makes no partial update, and a valid operation still completes.

Related illustrative findings: PII minimization and protected diagnostics; centralized log protection in the Azure review.