Application Source Code & AI/LLM Security Review

Section 1

Executive Summary

AI-enabled application security is a system property. Reviewing AI services, model inputs and outputs, frontend, API, worker, infrastructure and dependencies in isolation can miss the attack paths created at their seams.

This review method joins AI/LLM threat modeling, bounded model controls, adversarial regression, source inspection, repository analysis and software-supply-chain checks. It treats user input, uploaded documents, retrieved content and model output as untrusted until deterministic application controls validate and authorize the next action.

Assessment principle. The model can assist with classification or judgment, but identity, authorization, schemas, permitted actions and high-impact approvals belong to deterministic application code.

Section 2

Scope and Reviewed Technology

The reviewed application pattern combines Azure AI document understanding and model-assisted processing (Azure AI Document Intelligence and Azure OpenAI in Azure AI Foundry) with a React and TypeScript web application, Python 3.12 and FastAPI APIs, an asynchronous Python worker, Docker, Bicep and Azure DevOps.

Supporting Azure services include application hosting on Azure Container Apps, Azure App Configuration, Azure Blob and Queue Storage, an operational document database on Azure Cosmos DB, a dedicated secret store in Azure Key Vault and centralized monitoring with Azure Monitor.

AI/LLM boundaries and deterministic controls
Adversarial regression and verification behavior
Frontend authentication flows
API authorization boundaries
Request and response contracts
File ingestion and conversion
Asynchronous queue processing
Service-to-service access
Infrastructure and deployment scripts
Dependency and container risk

The reviewed flow (illustrative)

Sequence diagram of the illustrative document-processing flow: upload and intake, conversion under budgets, AI analysis at the untrusted-content boundary, bounded output handling, human review and assembly, and telemetry, with a security checkpoint annotated at each hop. — The illustrative document-processing flow with a security checkpoint at every hop. Fictional and representative; the lifeline groups follow the review's four boundaries. See also the reference architecture in the Azure review.

Review lenses per component

Component	What the review examines	Representative risks (Microsoft-documented)
React + TypeScript frontend	Authentication flows, token storage and configuration exposure	Script-readable token storage; backend-only configuration reaching the browser
FastAPI API	Authentication and authorization per operation, contracts and error handling	Missing object-level authorization; mass assignment through permissive contracts; detailed errors reaching callers
Async Python worker	Queue trust, identity scope and processing isolation	Unauthenticated or replayable work items; one identity spanning many data scopes
File ingestion and conversion	Format validation and resource budgets	Unbounded conversion of attacker-controlled files ahead of paid processing
Azure AI Document Intelligence + Azure OpenAI	Prompt construction, output handling and callback trust	Document-borne instructions steering the model; free-form output reaching persistent records; unvalidated callback addresses
Dependencies (pip-audit, npm audit)	Known vulnerabilities prioritized by data exposure	Vulnerable packages on the client-data path; unpinned transitive dependencies
Containers (Trivy)	Image contents, base layers and runtime user	Vulnerable base images; containers running as root; stale digests
Delivery (Azure DevOps) [planned]	The designed pipeline: scans, gates, identities and rollback	Secrets in repository history; mutable image references; missing approval gates

Review lenses are generic and drawn from Microsoft security-baseline and Well-Architected guidance. Representative risks are typical finding categories for each component, not engagement findings.

Section 3

Methodology

Trace critical flows. Follow user and document actions across browser, API, worker, storage and AI boundaries.
Review enforcement points. Locate authentication, authorization, validation, error handling and service access in code.
Assess dependencies. Compare locked packages and container inputs with public vulnerability data.
Threat-model AI behavior. Examine direct and indirect prompt injection, disclosure, unsafe output and excessive agency.
Challenge observations. Use complementary model roles and human review to test evidence and confidence.
Define verification. Give accepted remediation work an observable completion condition rather than a prose recommendation alone.

How severity is assigned: each example's severity derives from its ease of attack and potential impact. In a real engagement the Confidence field reflects evidence strength; in this public edition it always reads "fictional example".

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.

Section 4

AI and LLM Threat Model

Prompt injection is an application-security problem, not only a model problem. Instructions can arrive directly from a user or indirectly through documents, email, images, retrieved records or other content the application asks the model to process.

Direct prompt injection (OWASP LLM01)
Indirect document-borne instructions (OWASP LLM01)
Sensitive-information disclosure (OWASP LLM02)
Improper model-output handling (OWASP LLM05)
Excessive agency (OWASP LLM06)
Tool and privilege misuse (OWASP LLM06)
Poisoned or misleading content (OWASP LLM04, LLM09)
Resource and cost abuse (OWASP LLM10)

Security boundary. Content filtering can reduce risk, but it does not replace identity, authorization, schema validation, least privilege or deterministic approval for high-impact actions.

Fictional Security Examples

Illustrative AI and LLM Threat Examples

Illustrative only - not an engagement finding

Document-Borne Instructions Influence Cross-Customer Data Access

Critical See where this finding applies on the diagrams: AI services zone · AI analysis step · CP5 AI-call boundary

Ease of Attack: Requires crafted document content
Impact: Cross-customer retrieval or disclosure
Detection Difficulty: Requires tracing model output into retrieval and authorization code
Pattern: Example prompt-injection boundary pattern

Business Summary: Every uploaded document is untrusted model input. If instructions hidden in that content can influence retrieval or authorization, prompt injection stops being only a model quality problem and becomes a way for one customer's data to reach another.
Possible Weakness: Text embedded in a PDF, email or image instructs the model to request another customer’s records, and the application code acts on whichever record identifier or search scope the model chose, without checking it.
Potential Impact: Sensitive records could cross a tenant boundary or be included in a model response, log entry or generated working paper.
What an Assessment Verifies: Trace document content through prompt construction in the async worker, the Azure AI Document Intelligence and Azure OpenAI calls, the decisions about which records may be retrieved and the downstream Cosmos DB writes, using test documents that hide adversarial instructions and made-up customer records with known permissions.
Expected Fix: Keep tenant scope and authorization in deterministic FastAPI and worker code, treat document text only as data and never let Azure OpenAI output expand identity, retrieval or tool permissions.
How to Check the Fix: A reviewed set of documents carrying hidden instructions must never retrieve or reveal another tenant’s planted test data, while authorized classification continues to work and every attempted scope change is logged safely.

Cross-Reference Evidence (Illustrative). This is cross-reference evidence showing how prompt construction, authorization code and adversarial test output are reviewed together. 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 prompt and authorization 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 indirect-injection regression 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"}
```
Example AI workload-identity 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

Model and Error Paths Disclose Sensitive Document Content

High See where this finding applies on the diagrams: AI services zone · telemetry and error paths · CP8 telemetry separation

Ease of Attack: Depends on output or log access
Impact: PII disclosure across unintended surfaces
Detection Difficulty: Visible in log and API response inspection
Pattern: Example minimization-and-masking pattern

Business Summary: Tax documents are dense with personally identifiable information. Copies can escape the approved workflow through model responses, prompts, traces, errors or support logs even when the primary data store is protected.
Possible Weakness: Full document text, prompts or model responses are returned to callers or retained in broadly accessible logs without masking or data-minimization rules.
Potential Impact: Names, identifiers and financial details could reach unauthorized users, support tooling or telemetry audiences with longer retention than the source document.
What an Assessment Verifies: Plant recognizable fake personal details in test documents and trace them across model input, output, errors, application logs, Azure Monitor telemetry and status records persisted in Cosmos DB.
Expected Fix: Minimize what the model sees, mask personal details before Azure OpenAI calls where appropriate, validate outputs and keep sensitive traces in narrowly controlled Log Analytics tables with explicit retention.
How to Check the Fix: The planted fake details must never appear in responses, errors or logs, and may appear only in the explicitly approved protected records the business workflow needs.

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

Untrusted Document Text Alters Classification Behaviour

Medium See where this finding applies on the diagrams: AI services zone · AI analysis step · CP5 AI-call boundary

Ease of Attack: Requires crafted model input
Impact: Misclassification and workflow disruption
Detection Difficulty: Requires adversarial test documents and output comparison
Pattern: Example bounded-classification pattern

Business Summary: Even when a model cannot take privileged action, hidden instructions can still bias classification, increase manual review and route documents through the wrong business process.
Possible Weakness: Instructions embedded in a document tell the model to ignore classification rules, select a preferred category or report an unjustified confidence score.
Potential Impact: Documents could be misclassified, omitted from the expected workflow or accepted with misleading confidence, reducing the reliability of the final working paper.
What an Assessment Verifies: Run direct and indirect injection cases across PDFs, emails and images and compare the Azure OpenAI classification category, confidence, whether the model declines to answer, and reviewer presentation with a reviewed baseline.
Expected Fix: Constrain Azure OpenAI classification to a closed category set, separate instructions from document content and require human review through the confidence-based stoplight screen.
How to Check the Fix: Injection cases must remain within the closed category schema, surface uncertainty or decline to answer when appropriate and always remain subject to a recorded human review before final assembly.

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"}
```

Assessed control pattern - not an engagement finding

Bounded, Deterministic LLM Controls

Design position See where these controls apply on the diagrams: AI services zone · AI analysis step · CP5 AI-call boundary

The surrounding application should assume that model behavior can be manipulated or can drift. Controls therefore constrain what information the model receives, what shape it can return and what the application will permit afterward.

Schema-validated model inputs and outputs.
Closed or allow-listed actions instead of open-ended tool access.
Retrieval limited to the caller's permissions, and tenant separation.
Least-privilege workload identities and downstream authorization.
Human approval for high-impact, external or irreversible actions.
Audit records connecting model input, output, decision and resulting action.

Section 5

Adversarial Regression and Guardrail Drift

Model, prompt and data changes can alter security behavior without a conventional code defect. Replayable test cassettes (recorded model interactions) and adversarial regression cases provide a stable way to compare releases and detect changes in prompt-injection resilience, output validation and tool use.

Delivery pattern. Keep a reviewed test set of direct and indirect injection cases, disclosure attempts, malformed outputs and requests for unsafe actions. Run it when models, prompts, retrieval sources or control code change, then retain the result as release evidence.

Fictional Security Examples

Illustrative Regression and Guardrail Examples

Illustrative only - not an engagement finding

Model Output Can Select an Unapproved Downstream Action

Critical See where this finding applies on the diagrams: model output path · bounded output handling · CP5 AI-call boundary

Ease of Attack: Requires manipulated model output
Impact: Unauthorized external or irreversible action
Detection Difficulty: Visible in source review of how model output becomes actions
Pattern: Example bounded-agency pattern

Business Summary: A model may recommend an action, but it should not decide what the application is authorized to change, send or delete. High-impact authority belongs to deterministic code and accountable people.
Possible Weakness: Free-form model output is interpreted as a tool, destination or operation and executed without an allow-list, independent authorization or human approval.
Potential Impact: Manipulated or malformed output could trigger data disclosure, destructive changes, external communication or paid processing beyond the intended workflow.
What an Assessment Verifies: Trace every consumer of Azure OpenAI output, tool permission, destination rule, authorization check and approval step from response parsing in the async worker to the final side effect.
Expected Fix: Map model output only to closed, schema-validated actions in the async worker, reauthorize in code and require human approval for external, irreversible or high-impact operations.
How to Check the Fix: Actions, destinations and parameters outside the approved set must be rejected, and every high-impact test request must stop at a recorded human approval before any side effect occurs.

Cross-Reference Evidence (Illustrative). This is cross-reference evidence showing how the model-output consumer, tool policy and approval test are connected. 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 reference for mapping output to actions
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 test rejecting an unsafe action
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 least-privilege workload 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

Free-Form Model Output Reaches Persistent Records

High See where this finding applies on the diagrams: model output path · bounded output handling

Ease of Attack: Requires malformed or manipulated output
Impact: Persistent corruption or unsafe rendering
Detection Difficulty: Visible in source review of the code paths that write records
Pattern: Example schema-enforcement pattern

Business Summary: Model output becomes part of the trusted system when it is stored, rendered or assembled into a client deliverable. Free-form text can violate data contracts and carry unsafe content forward.
Possible Weakness: An application writes model-generated categories, identifiers or document content into records or reports without a closed schema, escaping and deterministic validation.
Potential Impact: Malformed values could corrupt workflow state, inject active content, break final documents or place unreviewed text into a customer deliverable.
What an Assessment Verifies: Inspect response contracts, parser failure behaviour, Cosmos DB constraints, rendering contexts and the human-review boundary before final PDF assembly.
Expected Fix: Constrain model responses to closed categories and typed schemas, reject additional fields before Cosmos DB writes, escape every rendering context and require review before the final PDF.
How to Check the Fix: Malformed, additional and out-of-category fields must fail closed, while valid outputs persist safely and only human-approved classifications appear in the final test working paper.

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

Prompt Changes Ship Without Adversarial Regression Evidence

Medium See where this finding applies on the diagrams: delivery zone [planned] · AI analysis step · CP6 supply-chain gate

Ease of Attack: Not an attack path; permits guardrail drift
Impact: Known AI security failures can reappear
Detection Difficulty: Apparent from missing release test evidence
Pattern: Example adversarial-release pattern

Business Summary: A prompt, model or retrieval change can alter security behaviour without changing ordinary application tests. A release needs evidence that known injection and disclosure cases did not regress.
Possible Weakness: Model, prompt, retrieval or output-handling changes reach release without replaying a reviewed test set of direct and document-borne injection cases, disclosure attempts and malformed outputs.
Potential Impact: A previously contained attack pattern could reappear silently, or guardrails could drift while conventional code tests continue to pass.
What an Assessment Verifies: Review adversarial test coverage, where the replayable test cassettes come from, model and prompt versioning, approval of expected results, Azure DevOps release gates and retained comparison evidence.
Expected Fix: Run a versioned set of adversarial test cases whenever models, prompts, retrieval sources or control code change and block the Azure DevOps release on an unapproved security regression.
How to Check the Fix: Known cases covering direct and indirect injection, PII disclosure, malformed output and unsafe actions must run on every relevant change, fail the release when they regress and retain results as release evidence.

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"}
```

Section 6

Application and Service Boundaries

The review connects frontend behavior with backend enforcement. A user interface can hide or disable an action, but only the API and downstream service can enforce whether the caller is allowed to perform it.

Boundary	Review question
Browser to API	Are identity, authorization and object ownership rechecked for every operation?
API to worker	Can queued work be authenticated, constrained, replayed safely and attributed?
Worker to data services	Does each workload use the smallest identity and data scope it requires?
Application to AI service	Are model input, output and permitted downstream actions bounded by code?

Fictional Security Examples

Illustrative Application Boundary Examples

Illustrative only - not an engagement finding

Signed-In Users Can Cross Customer Record Boundaries

Critical See where this finding applies on the diagrams: application zone · upload and intake step · CP1 public ingress

Ease of Attack: Low effort for a valid user
Impact: Cross-customer document and PII access
Detection Difficulty: Requires per-object authorization tests across tenants
Pattern: Example object-authorization pattern

Business Summary: Sign-in proves who a caller is, but it does not prove that the caller may read or change every customer record exposed by an API.
Possible Weakness: An API accepts a customer or record identifier and performs the requested operation without rechecking ownership, tenant membership or role at the object boundary.
Potential Impact: A valid user could read, change or delete another customer’s documents and personally identifiable information.
What an Assessment Verifies: Trace authorization from FastAPI routes through service functions to Cosmos DB queries, compare it with the approved role matrix and run safe cross-customer negative tests using made-up customer records.
Expected Fix: Enforce default-deny object and tenant authorization in server-side FastAPI code for every read, update, retry and deletion operation.
How to Check the Fix: A user assigned to one test customer must receive 403 for every operation on another customer’s records without learning whether the target record exists.

Cross-Reference Evidence (Illustrative). This is cross-reference evidence showing how route, service and negative-test evidence support one authorization conclusion. 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 authorization permalink
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 cross-customer negative-test 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"}
```
Example API identity configuration 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

Privileged API Operations Lack Role Enforcement

High See where this finding applies on the diagrams: application zone · upload and intake step · CP1 public ingress

Ease of Attack: Low effort for a signed-in user
Impact: Unauthorized configuration or data changes
Detection Difficulty: Visible in a review of authorization on each route
Pattern: Example function-role pattern

Business Summary: Some operations can change system behaviour, repeat processing or remove records. Signing in should not automatically grant every user permission to perform those higher-impact actions.
Possible Weakness: Privileged API routes require a signed-in identity but do not enforce an approved role for configuration, retry, update or deletion functions.
Potential Impact: An ordinary user could change processing behaviour, repeat paid work or alter and delete records outside their responsibilities.
What an Assessment Verifies: Map every sensitive FastAPI route to an approved Entra ID role, then trace enforcement through route dependencies, service functions and the data layer.
Expected Fix: Apply a default-deny policy in server-side code that maps each function to an approved Entra ID role and repeat the decision near destructive or irreversible data operations.
How to Check the Fix: For each role, every unapproved privileged operation must return 403 without changing data, while approved operations complete and record the actual actor.

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

Record Updates Accept Fields the Caller Should Not Control

Medium See where this finding applies on the diagrams: application zone · upload and intake step

Ease of Attack: Requires update access and field knowledge
Impact: Ownership, workflow or audit corruption
Detection Difficulty: Visible in API contract and handler field review
Pattern: Example update-contract pattern

Business Summary: A convenient update that accepts the whole record can let callers change ownership, identity or system-managed fields that the business process never intended them to control.
Possible Weakness: An API accepts a caller-supplied record object and writes every field without an allow-list of properties that may be changed.
Potential Impact: A caller could reassign a record, bypass workflow state, overwrite audit context or corrupt fields used by later processing.
What an Assessment Verifies: Compare FastAPI request schemas with domain ownership rules, trace the update to persistence and identify every server-managed field.
Expected Fix: Use purpose-specific update contracts, allow-list the fields callers may change and set ownership, audit and workflow state only in trusted server code.
How to Check the Fix: Attempts to change ownership, actor, tenant or protected workflow fields must be rejected or ignored, while explicitly permitted business fields update correctly.

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"}
```

Section 7

Files, APIs and Safe Output Handling

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.

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"}
```

Section 8

Software Supply-Chain Assessment

The review combines manual source and infrastructure analysis with layered security tooling. Tool output is weighed against the application’s real code paths instead of being treated as a raw vulnerability count.

Tool or standard	Purpose
Gitleaks	Detect likely secrets in the current tree and available history.
pip-audit and npm audit	Compare resolved Python and JavaScript dependencies with public advisories.
Trivy	Assess container inputs and vulnerabilities in the image itself.
CWE, OWASP and ASVS	Classify weakness patterns and connect them to verifiable security requirements.

Fictional Security Examples

Illustrative Supply-Chain Examples

Illustrative only - not an engagement finding

Build Materials Contain a Long-Lived Service Secret

Critical See where this finding applies on the diagrams: delivery zone [planned] · CP7 workload identity federation

Ease of Attack: Low effort after obtaining a repository copy
Impact: Unauthorized service use or data access
Detection Difficulty: Visible in repository history secret scanning
Pattern: Example secret-removal pattern

Business Summary: A service key committed to deployment source or copied into build output remains recoverable from history and artifacts even after the latest file is cleaned up.
Possible Weakness: Infrastructure code, setup scripts or documentation contain a reusable cloud credential that is also preserved in repository history.
Potential Impact: Anyone with a repository clone or retained artifact could use the service outside the application until the credential is revoked.
What an Assessment Verifies: Use secret scanning across the current tree, repository history and build artifacts, then determine whether an Entra ID managed identity can replace the credential without attempting to use it.
Expected Fix: Revoke and rotate the credential, purge stored copies, move the workload to an Entra ID managed identity and gate every merge and release in Azure DevOps with secret scanning.
How to Check the Fix: The old value must be rejected, scans that include repository history must find no copy, the workload must operate without a stored key and a planted test secret must fail the pipeline.

Cross-Reference Evidence (Illustrative). This is cross-reference evidence demonstrating how one secret concern is supported by multiple independent evidence types. 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 and history 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 Gitleaks-style scan 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"}
```
Example managed-identity configuration 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

Known Vulnerable Dependency Handles Untrusted Documents

High See where this finding applies on the diagrams: delivery zone [planned] · CP6 supply-chain gate

Ease of Attack: Depends on advisory prerequisites
Impact: Unsafe parsing, exhaustion or code execution
Detection Difficulty: Visible in dependency audit output
Pattern: Example reachable-dependency pattern

Business Summary: A package advisory matters most when the affected component is reachable from hostile input. Document parsers and upload readers sit directly on that path.
Possible Weakness: A resolved Python or JavaScript dependency with a published security fix processes attacker-controlled files before application-level validation can contain the behaviour.
Potential Impact: A crafted upload could trigger resource exhaustion, unsafe parsing or code execution in a service that handles sensitive documents.
What an Assessment Verifies: Confirm the resolved Python or npm package version, whether the advisory applies, whether hostile input can reach the affected code, what an exploit would require and whether that code runs in the Container Apps workloads or only in build tooling.
Expected Fix: Upgrade or remove the package, lock the corrected version and use Azure DevOps dependency gates that prioritize the reachable packages handling client data.
How to Check the Fix: The clean build must resolve the corrected version, dependency scanning must pass and a safe regression case must show that the vulnerable processing behaviour is no longer reachable.

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

Container Scan Results Do Not Block Release Promotion

Medium See where this finding applies on the diagrams: delivery zone [planned] · CP6 supply-chain gate

Ease of Attack: Depends on the reported vulnerability
Impact: Known risk reaches production unchanged
Detection Difficulty: Visible in a review of pipeline policy and scan gates
Pattern: Example release-policy pattern

Business Summary: A scanner creates a report, not a control. The result becomes operationally useful only when release policy blocks unacceptable risk or records a governed exception.
Possible Weakness: Container scanning reports high-severity packages, moving base-image tags or missing image metadata, but the release continues without a policy decision.
Potential Impact: A known vulnerable or unverifiable image could reach production even though the delivery system already had enough information to stop it.
What an Assessment Verifies: Inspect Azure Container Registry image inputs, Trivy output, severity thresholds, how reported issues are checked for real exposure, who owns exceptions, digest-based promotion and the evidence linking source to image.
Expected Fix: Promote only digest-identified images from Azure Container Registry that meet policy, with human-approved, time-limited exceptions and retained evidence linking source, build and scan result.
How to Check the Fix: A controlled image that deliberately violates release policy must fail promotion, while an approved exception must expire automatically and remain visible in release evidence.

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"}
```

Section 9

Relationship to the Azure Review

The Azure review assesses running configuration, service relationships and observable operational controls using safe, read-only evidence. The application review assesses source code, infrastructure as code, dependencies and delivery artifacts. Areas of overlap are intentionally compared. Agreement between the two evidence streams strengthens confidence, while differences reflect their distinct scopes and evidence boundaries.

Read the companion Azure architecture, deployment and operational security review.

Section 10

Public Edition and Disclosure

This purpose-built public edition is intended for external sharing. It contains no client names, tenant or subscription identifiers, resource names, internal URLs, work-item references, source paths, commit identifiers, screenshots, sample data, credentials, or combinations of details that could reconstruct a specific finding.

The severity-labelled material in Sections 4 through 9 consists only of newly authored fictional examples. It does not report, summarize or imply any engagement finding or actual severity rating.

Cross-reference links point only to newly authored demonstration evidence in Section 10. They are not client source links, Azure resource links or engagement tool output.

Section 11

Limitations

This report explains the assessment scope, methodology, control domains and generalized security lessons. It does not reproduce client-specific findings, severity ratings, evidence, remediation status or current production configuration. It is not a penetration-test report, certification, assurance opinion or statement that any example weakness was present. Inclusion of a topic means it was assessed, not that a finding existed. Severity labels apply only to the fictional examples and illustrate prioritization methodology.

Section 12

Public References

Application Source Code & AI/LLM Security Review · Full Edition

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

Back to the chaptered edition