Files, APIs and Safe Output Handling

Illustrative Findings Boundary

The severity-labelled scenarios below are newly authored fictional examples informed by the control domains assessed in this work. They do not reproduce or summarize any engagement finding, do not describe the reviewed environment, and do not indicate that any weakness was observed, confirmed, remediated or remains outstanding. Severity labels apply only to these examples and illustrate prioritization methodology.

Each example combines a plain-English business summary, a technical condition, potential impact, the evidence an assessment would seek, the expected control and a measurable way to check the fix.

Document workflows combine attacker-controlled filenames, file content, metadata, conversion libraries and model input. Each layer needs its own validation because a file can be valid at one layer and dangerous at another.

Verify actual file content instead of trusting the supplied extension or media type.
Apply limits on file size, page count, decompression, processing time and cost before expensive work.
Normalize storage paths and keep client or tenant authorization independent of filenames.
Treat model output as untrusted input before rendering, querying, writing files or calling privileged APIs.
Return useful errors without exposing implementation, credentials or sensitive document context.

Fictional Security Examples

Illustrative File and Output Handling Examples

Illustrative only - not an engagement finding

Active Uploaded Content Runs Inside a Trusted Staff Session

Critical See where this finding applies on the diagrams: browser-to-API-to-storage path · CP1 public ingress

Ease of Attack: Requires a crafted uploaded file
Impact: Staff-session actions and token exposure
Detection Difficulty: Requires an active-content upload and preview test
Pattern: Example preview-isolation pattern

Business Summary: A document preview is part of the application’s trust boundary. If active content runs with the same browser privileges as the staff site, an uploaded file can act as the signed-in reviewer.
Possible Weakness: The upload path trusts the caller’s filename and media type, then displays the stored file in an unrestricted same-origin preview frame.
Potential Impact: A disguised active file could read page data, invoke application APIs or obtain a staff access token available to browser scripts.
What an Assessment Verifies: Inspect content detection, Blob Storage response headers, preview isolation in the React web application, browser token storage and the permissions available to framed content.
Expected Fix: Verify actual file content, serve previews from an isolated origin or sandboxed frame, and keep Entra ID access tokens out of browser storage that scripts can read.
How to Check the Fix: A test file containing active content, disguised as an allowed document, must be rejected or rendered inert and must be unable to read the parent page, token storage or authenticated API responses.

Cross-Reference Evidence (Illustrative). This is cross-reference evidence showing how upload validation and the browser preview code combine into one attack path. In a real engagement each item below is a live pointer: a file-and-line link into the source repository, a reproducible read-only query against the deployed Azure environment, or replayable tool output. Here they lead to newly authored public demonstrations.

Example upload and preview source references
This is cross-reference evidence. A real assessment links the reviewed commit and exact lines across the route, service and data boundary so another reader can follow the complete control path.
```
if actor.tenant_id != record.tenant_id:
    raise Forbidden()
```
Example browser test of an inert preview
This is cross-reference evidence. A real report retains the tool version, safe test case, expected result and output needed to reproduce the conclusion.
```
security-regression --case "<illustrative-case>" --format json
Illustrative output: {"result":"blocked as expected"}
```
Example hosting and response-header record
This is cross-reference evidence. A real assessment records a dated read-only identity or configuration query and explains what that result does and does not prove.
```
az resource show --ids "<illustrative-resource-id>" \
  --query "identity.type"

Illustrative output: "SystemAssigned"
```

Illustrative only - not an engagement finding

Document Conversion Has No Enforced Resource Budget

High See where this finding applies on the diagrams: application zone · conversion under budgets step

Ease of Attack: Low effort with a crafted document
Impact: Service exhaustion and avoidable cloud cost
Detection Difficulty: Visible in converter configuration and limits review
Pattern: Example resource-budget pattern

Business Summary: Small uploads can expand into very large or complex processing jobs. Without per-format limits, one file can consume worker capacity and paid services needed by every user.
Possible Weakness: Document converters enforce an upload size but no limits for expanded bytes, pages, spreadsheet rows, image dimensions, processing time or memory.
Potential Impact: A compressed bomb, damaged file or unusually complex document could exhaust resources, delay legitimate work or create avoidable cloud cost.
What an Assessment Verifies: Trace every conversion path in the async worker, including behaviour when a file's declared size is missing, and measure local resource limits before Azure AI Document Intelligence or paid model processing begins.
Expected Fix: Apply per-format expansion, page, time and memory budgets in the isolated async worker so conversions can be stopped without affecting the public API.
How to Check the Fix: Test uploads built as compression bombs, oversized spreadsheets, page-heavy documents, missing size values and slow conversions must stop within the approved budget before paid processing starts.

Cross-Reference Evidence (Illustrative). This is cross-reference evidence showing how the private reports connect this example’s verification to complementary sources. In a real engagement each item below is a live pointer: a file-and-line link into the source repository, a reproducible read-only query against the deployed Azure environment, or replayable tool output. Here they lead to newly authored public demonstrations.

Example source-code evidence reference
This is cross-reference evidence. A real assessment links the reviewed commit and exact lines across the route, service and data boundary so another reader can follow the complete control path.
```
if actor.tenant_id != record.tenant_id:
    raise Forbidden()
```
Example read-only Azure evidence record
This is cross-reference evidence. A real assessment records a dated read-only identity or configuration query and explains what that result does and does not prove.
```
az resource show --ids "<illustrative-resource-id>" \
  --query "identity.type"

Illustrative output: "SystemAssigned"
```
Example reproducible tool output
This is cross-reference evidence. A real report retains the tool version, safe test case, expected result and output needed to reproduce the conclusion.
```
security-regression --case "<illustrative-case>" --format json
Illustrative output: {"result":"blocked as expected"}
```

Illustrative only - not an engagement finding

Detailed Errors Expose Sensitive Processing Context

Medium See where this finding applies on the diagrams: operations zone · telemetry and error paths · CP8 telemetry separation

Ease of Attack: Triggered through safe failure paths
Impact: Disclosure of PII and implementation details
Detection Difficulty: Requires triggering failures and inspecting what errors reveal
Pattern: Example error-sanitization pattern

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.
Possible Weakness: Raw exceptions and downstream service responses are returned through API errors or written to logs and records without masking sensitive values first.
Potential Impact: An unauthorized caller or log reader could learn implementation detail or personally identifiable information that helps further probing.
What an Assessment Verifies: Exercise safe failure paths across upload, conversion, Blob Storage and model calls, then trace what reaches the browser, FastAPI error responses, application logs and status records in Cosmos DB.
Expected Fix: Return stable public error codes from the FastAPI services, retain sensitive diagnostics only in protected Azure Monitor telemetry and mask document, customer and model content by default.
How to Check the Fix: Malformed test requests must produce useful but generic client errors, while protected logs retain a correlation identifier and only the minimum approved diagnostic context.

Example source-code evidence reference
This is cross-reference evidence. A real assessment links the reviewed commit and exact lines across the route, service and data boundary so another reader can follow the complete control path.
```
if actor.tenant_id != record.tenant_id:
    raise Forbidden()
```
Example read-only Azure evidence record
This is cross-reference evidence. A real assessment records a dated read-only identity or configuration query and explains what that result does and does not prove.
```
az resource show --ids "<illustrative-resource-id>" \
  --query "identity.type"

Illustrative output: "SystemAssigned"
```
Example reproducible tool output
This is cross-reference evidence. A real report retains the tool version, safe test case, expected result and output needed to reproduce the conclusion.
```
security-regression --case "<illustrative-case>" --format json
Illustrative output: {"result":"blocked as expected"}
```

Application Review · Control Domain 4 of 5 · Public Edition

Part of the two-report public security-review portfolio.

Report overview