Application and AI Security Review

Executive Summary

One manipulated AI response can expose trusted data or trigger a system action. Reviewing the AI, web pages, connected systems, background work, cloud setup and third-party software separately can miss the attack paths where they connect.

This review checks how attackers could manipulate the AI, whether safeguards still work after changes, what the source code allows, and whether third-party software introduces risk.

It treats every user message, uploaded document, piece of information pulled from another system, and AI response as potentially unsafe.

Trusted application code must check that content and decide whether the next action is allowed.

Assessment Principle

AI provides semantic reasoning. It interprets meaning, classifies information and supports human judgment.
Deterministic code keeps control. The application, not the AI, controls identity, permissions, data formats, allowed actions and high-impact approvals.

Scope and Reviewed Technology

Application: This demonstration follows a web application that uses AI to read and process documents. The browser is built with React and TypeScript. FastAPI services and a background Python worker perform the work.
Azure platform: Azure Container Apps hosts the services. Azure Blob Storage and Queue Storage hold files and work items. Azure Cosmos DB stores processing records. Azure App Configuration holds settings, Azure Key Vault protects secrets, and Azure Monitor collects logs.
Delivery and AI: Docker packages the services. Bicep and Azure DevOps define and deliver the cloud setup. The AI services are Azure AI Document Intelligence and Azure OpenAI in Azure AI Foundry.

The Example Flow

Sequence diagram of the illustrative document-processing flow: upload and intake, conversion within processing limits, AI analysis of potentially unsafe documents, checks before AI output is used, human review and assembly, and logging, with a security check at each step. — The illustrative document-processing flow with a security check at every step. Fictional and representative; the diagram columns follow the review's four parts of the system. See also the reference architecture in the Azure review.

What We Check in Each Component

Component	What we check	What could go wrong
Application code
React + TypeScript frontend	How users sign in, where access tokens (the digital proof of sign-in) are stored and whether server-only settings reach the browser	Browser scripts can read an access token Private server settings are sent to the browser
FastAPI API	Who can perform each system action, which fields a request may change and what errors reveal	A signed-in user reaches another customer's records Callers change protected fields Errors expose internal details
Background Python worker	Whether queued work is genuine, what the worker identity can access and how jobs are isolated	Forged or repeated work items One worker identity can reach too much data
Document and AI processing
File uploads and conversion	Whether the file is really an allowed type and how much processing one file may consume	A hostile file exhausts processing capacity before paid AI services begin
Azure AI Document Intelligence + Azure OpenAI	Instructions sent to AI, checks on AI responses and which service addresses the application follows	A document manipulates the AI An unchecked AI response becomes a trusted record The worker follows an unsafe address
Software supply chain and delivery
Dependencies (pip-audit, npm audit)	Third-party packages with known vulnerabilities, ranked by whether untrusted data can reach them	An unsafe package processes customer data Indirect packages change without a locked version
Containers (Trivy)	Packages inside each image, its base image and the account it runs under	An unsafe base image A container runs with administrator rights A container image name can change
Delivery (Azure DevOps) [planned]	How code is scanned, approved, released and rolled back	Secrets remain in source history Image references can change Releases lack approval checks

How AI Can Be Manipulated

Prompt injection means giving an AI model instructions designed to manipulate its response. Those instructions can come directly from a user or hide inside documents, email, images, retrieved records or other content the application asks the model to process.

Threats covered

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 Denial of wallet OWASP LLM10

Resource and cost abuse, often called denial of wallet, can cause serious harm without a data breach. One crafted or oversized upload can trigger repeated model calls before anyone notices the rising bill. The review checks file limits, retry and queue limits, model quotas, and spend alerts with a named owner and response path.

Security boundary. Content filtering can reduce risk, but it does not replace sign-in, permission checks, data-shape validation or minimum necessary access. High-impact actions still need deterministic code: fixed application rules that produce the same decision from the same input.

Fictional Security Examples

Illustrative AI and LLM Threat Examples

Illustrative only - not an engagement finding

Uploaded Documents Can Make AI Access Another Customer's Data

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

Business summary

Every uploaded document is AI input that the application must not trust. If hidden instructions can influence which records are retrieved or who may access them, prompt injection can become a way for one customer's data to reach another.

Assessment profile

Ease of attack: Requires crafted document contentText in a PDF, email or image can request another customer’s records. The application becomes vulnerable when it trusts the model-selected record or search scope without rechecking it.
Impact: Cross-customer disclosure

Customer records containing personally identifiable information (PII) could cross a customer boundary.

PII could appear in an AI response, log entry or generated working paper.
Detection difficulty: Deep trace requiredTrace model output through retrieval, authorization and subsequent data access.
Pattern: Prompt-injection boundaryUntrusted document content influences which records the application retrieves.

Expected fix Verification

Expected fix Treat document text as data Azure AI Document Intelligence output and background-worker prompt construction: Keep extracted document text separate from application instructions.

Verification Ignore hidden instructions Test documents cannot reveal planted cross-customer data, while authorized classification still works.
Expected fix Derive scope server-side FastAPI authentication context and worker job payloads: Derive scope only from the signed-in user and server-side data.

Verification Protect server-derived scope Model-proposed identifiers cannot override the signed-in user's scope.
Expected fix Reauthorize every operation Cosmos DB and Blob Storage data-access methods: Recheck access immediately before every read or write.

Verification Recheck at the data boundary An out-of-scope request is denied immediately before the data operation.
Expected fix Validate model output strictly Azure OpenAI response parsing and schema validation: Reject unknown identifiers, actions, fields or destinations.

Verification Reject unknown output Unknown values are rejected before any database or storage operation.
Expected fix Mediate all data access Azure OpenAI integration and server-side data-access adapters: Give the model no database or storage credentials or direct route.

Verification Block direct model access The model has no credential or route to database or storage records.
Expected fix Fail closed and log safely FastAPI and background worker authorization failures: Deny scope changes and record them in server-side logs without document or customer content.

Verification Deny and log scope changes Each attempt is denied and logged without document or customer content.

Illustrative only - not an engagement finding

AI Responses and Error Messages Can Reveal Personally Identifiable Information

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

Business summary

Tax documents are dense with personally identifiable information (PII). Copies can escape the approved workflow through model responses, prompts, traces, errors or support logs even when the primary data store is protected.

Assessment profile

Ease of attack: Output or log accessA caller or support user can trigger or inspect responses that contain more document content than the workflow requires.
Impact: PII disclosure

Names, identifiers and financial details could reach unauthorized users or support tools.

Monitoring data could retain PII longer than the source document.
Detection difficulty: End-to-end content traceTrace planted test details through document analysis, model input and output, API errors, status records and monitoring logs.
Pattern: Minimize, mask and restrictDocument content crosses more application and monitoring surfaces than the approved business process requires.

Expected fix Verification

Expected fix Minimize model input Background worker after Azure AI Document Intelligence: Send Azure OpenAI only the fields required for classification.

Verification Limit model exposure Captured requests show that Azure OpenAI receives only the approved minimum fields.
Expected fix Mask details the model does not need Worker content-preparation step: Mask PII before the model call when classification does not require it.

Verification Preserve useful classification Planted unnecessary details are masked while authorized classification still produces the expected result.
Expected fix Redact every outbound surface FastAPI responses, worker errors, Cosmos DB status records and PDF assembly: Redact or reject PII before content leaves the approved workflow.

Verification Stop secondary disclosure Planted details do not appear in responses, errors, ordinary logs or unapproved status records, while approved output retains the minimum required information.
Expected fix Protect necessary diagnostic traces Azure Monitor and Log Analytics: Keep diagnostics containing PII or document content in dedicated tables with explicit retention.

Verification Expire protected traces Test traces are removed when the approved retention period ends.
Expected fix Restrict diagnostic access Log Analytics role assignments: Grant access to restricted diagnostic tables only to named support or security roles.

Verification Deny broad log access A user without an approved support or security role cannot read the restricted diagnostic tables.

Illustrative only - not an engagement finding

Document Text Can Change How AI Classifies It

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

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.

Assessment profile

Ease of attack: Crafted document inputHidden instructions in extracted text can ask the model to ignore the category rules or invent confidence.
Impact: Misclassification and workflow disruption

Documents could be omitted, misrouted or accepted with misleading confidence.

The final working paper could become less reliable.
Detection difficulty: Adversarial comparison requiredCompare crafted documents and model responses with a reviewed baseline and the recorded reviewer path.
Pattern: Bounded classificationUntrusted document content attempts to influence a closed-set category and confidence decision.

Expected fix Verification

Expected fix Keep categories closed Azure OpenAI classification deployment: Allow only the approved category list.

Verification Reject unknown categories Direct and document-borne injection cases stay inside the approved list, while normal cases still produce valid categories.
Expected fix Validate category and confidence Background-worker response parser: Enforce a strict schema and reject malformed values or additional fields.

Verification Reject malformed output Unknown categories, malformed confidence values and extra fields are rejected without saving a classification.
Expected fix Separate instructions from content Worker boundary between Azure AI Document Intelligence and Azure OpenAI: Treat extracted text only as data inside the classification prompt.

Verification Ignore document instructions Crafted PDFs, emails and images cannot replace the classification rules or force a preferred confidence value.
Expected fix Route uncertainty to people FastAPI review workflow and Cosmos DB status: Send uncertain, declined or below-threshold results to a recorded classification review.

Verification Require recorded review Every uncertain, declined or below-threshold result enters the recorded classification review before it is accepted.
Expected fix Preserve original model evidence Cosmos DB review audit and PDF assembly: Store the original category, confidence and model evidence beside any reviewer correction.

Verification Keep corrections auditable An approved reviewer can correct the result without changing or replacing the original model evidence.

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

Content filtering can reduce harmful model responses, but it does not replace authorization, output validation or approval in application code.

Document and data access: keep customer scope in server-side code and treat uploaded content as untrusted. See document-borne prompt injection.
Classification and output handling: constrain categories and validate every response before storage or display. See bounded classification and output validation.
System actions and retesting: require application approval for actions and replay known attacks after relevant changes. See action controls and security regression evidence.

Retesting AI Safety After Changes

A model, prompt, analyzer or searchable-data change can alter security behaviour even when ordinary application tests still pass.

Reusable attack-test pack

Direct prompt-injection attempts
Hidden instructions inside documents
Attempts to reveal personally identifiable information (PII)
Invalid AI responses and unauthorized-action requests

See AI safety regression evidence for when the pack runs, what blocks release and which evidence the team retains.

Fictional Security Examples

Illustrative Regression and Guardrail Examples

Illustrative only - not an engagement finding

AI Can Trigger a System Action That Was Not Approved

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

Business summary

An AI response is untrusted text, not permission to act. The application must never turn it directly into an email, database change, file deletion, paid operation or other system action. Before anything happens, server-side rules must check the signed-in user, the affected customer, the requested action and any required human approval.

Assessment profile

Ease of attack: A manipulated response becomes a commandAn attacker changes the model's response, and the application uses it to choose a tool, destination or operation without an independent check.
Impact: Unauthorized system action

Model output could trigger disclosure, destructive changes or external communication.

It could start paid processing outside the intended workflow.
Detection difficulty: Follow the response to the final actionTrace the Azure OpenAI response through the worker, permission checks, approval step and resulting operation.
Pattern: The model recommends; the server decidesThe model may suggest an action, but fixed server-side rules must decide whether it is allowed.

Expected fix Verification

Expected fix Keep every operation behind application code Background worker and server-side service adapters: Give Azure OpenAI no credentials and no direct route to tools or connected services.

Verification Confirm the model cannot act directly The model has no credential or connection that can invoke a tool or connected service.
Expected fix Allow only defined actions Worker action-selection code: Match a checked model response to a fixed list of actions and permitted fields.

Verification Reject unsupported actions Unknown actions, destinations and values fail before anything is sent, changed or charged.
Expected fix Take customer and destination details from the server FastAPI sign-in context and worker jobs: Set the customer, destination and permitted values from trusted server data, not from the model response.

Verification Ignore model-proposed scope changes A customer, destination or value proposed by the model cannot replace the trusted server value.
Expected fix Check permission immediately before acting Server-side action and data-access code: Recheck the signed-in user and customer immediately before each operation.

Verification Deny the action at the final boundary An otherwise valid action with the wrong customer or user permission is denied immediately before execution.
Expected fix Require accountable approval FastAPI review workflow and worker action state: Require a named person's recorded approval before any external, irreversible or high-impact operation.

Verification Stop before high-impact work Every external, irreversible or high-impact test action waits for recorded human approval.
Expected fix Record who requested and approved the action Azure Monitor and application audit logs: Record the user, requested action, approval, enforcing code and outcome without personally identifiable information (PII), document content or model output.

Verification Keep actions traceable The audit trail identifies the user, request, approval, enforcing code and outcome without storing PII or document content.

Illustrative only - not an engagement finding

Unchecked AI Responses Can Be Saved as Trusted Records

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

Business summary

An AI response can contain invented categories, unexpected fields, unsafe links or code-like text. If the application saves or displays it without checking, those values can corrupt a customer record, run in a browser or appear in the final working paper.

Assessment profile

Ease of attack: An unexpected AI response is acceptedThe model returns an invented category, identifier, field or piece of document content, and the application saves it without applying fixed validation rules.
Impact: Incorrect records or unsafe displayed content

Unexpected values could put a record into the wrong workflow state or cause active content to run.

Unchecked AI text could reach a customer's final working paper.
Detection difficulty: Follow the response to every destinationInspect how the response is checked, written to Cosmos DB, displayed in React and approved before PDF assembly.
Pattern: Check before saving or displayingAccept only expected Document Intelligence and Azure OpenAI values before they reach storage, the browser or a working paper.

Expected fix Verification

Expected fix Define exactly what a valid response contains Document Intelligence and Azure OpenAI response models: Accept only named categories, expected fields and required data types.

Verification Accept a valid response A response with an approved category, fields and data types is checked and saved correctly.
Expected fix Stop when a response cannot be checked Background-worker response checks: Stop when the response cannot be read or fails validation, and do not save part of the workflow state.

Verification Save nothing from an invalid response An invalid response fails before any classification or workflow value is saved.
Expected fix Reject unexpected values before saving Cosmos DB data-access code: Reject extra fields, unknown values and categories that are not approved before every write.

Verification Keep unexpected output out of Cosmos DB Extra fields, unknown values and unapproved categories are rejected before a Cosmos DB operation occurs.
Expected fix Display AI text as text, not code React, application logs and PDF assembly: Encode model content for each destination so it cannot be interpreted as HTML, script or a control sequence.

Verification Keep active content harmless HTML, script syntax and control characters remain inert in browser, PDF and log output.
Expected fix Require review before delivery FastAPI review state, Cosmos DB and PDF assembly: Allow only recorded, human-approved model content into the final working paper.

Verification Publish reviewed content only Only human-approved classifications and content appear in the final test working paper.

Illustrative only - not an engagement finding

AI Safety Changes Can Ship Without Retesting

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

Business summary

Changing the AI model, the instructions it receives, how documents are analyzed or the information it can search may allow an attack that the previous release blocked. Before release, the team must rerun known attacks and normal user tasks. If an attack succeeds, a normal task fails or a required result is missing, the release must stop.

Assessment profile

Ease of attack: A change can weaken protection silentlyA new model, instruction, analyzer or response-handling change can behave differently while ordinary application tests continue to pass.
Impact: Previously blocked attacks can work again

Prompt injection or PII disclosure that was blocked before could return.

AI output checks or action limits could weaken without an obvious application error.
Detection difficulty: Ordinary tests may still passThe problem appears only when the same attack and normal-use tests are run against the changed AI setup and compared with the approved result.
Pattern: Retest attacks before every releaseEvery AI-related change must run the approved attack tests and normal business cases before deployment.

Expected fix Verification

Expected fix Store the exact test setup Security-test evidence store: Keep the attack cases, test documents, approved results, Document Intelligence analyzer, Azure OpenAI deployment, instructions and response format together under version control.

Verification Show exactly what was tested The release record names every model, analyzer, instruction set, response format, test document and approved result used by the run.
Expected fix Rerun tests after every relevant change Azure DevOps security-regression job: Run the versioned set when AI services, prompts, response handling or control code change.

Verification Test attacks and normal work together Every relevant change runs the complete set. Known attacks stay blocked and normal business cases still work.
Expected fix Require approval when a result changes Azure DevOps protected review: Require a named reviewer to explain and approve every changed expected result.

Verification Reject unapproved result changes A changed expected result cannot pass the release gate without the named review and approval.
Expected fix Stop release when protection gets weaker Azure DevOps release gate: Stop release when a required result is missing or a previously blocked attack now succeeds.

Verification Block missing or failed security results A missing result or newly successful attack case blocks release.
Expected fix Keep the results with the release Azure DevOps release artifacts: Store the result comparison, reviewer identity and approval with the release record.

Verification Make the release decision reviewable The release record keeps the exact test comparison and named approval that allowed deployment.

Who Can Access Records and System Actions

Hiding or disabling a button only changes what the user sees. A user can still call the API directly with browser tools or another program. The API and the services it calls must therefore check the signed-in person's permission before every read, change or system action.

Boundary	Review question
Browser to API	Are sign-in, permissions and record ownership checked again for every operation?
API to worker	Can background work be authenticated, limited, repeated safely and traced to the person or service that started it?
Worker to data services	Does each service use only the identity and data access it needs?
Application to AI service	Does fixed application code limit the model's input, output and any later action?

Fictional Security Examples

Illustrative Application Boundary Examples

Illustrative only - not an engagement finding

Signed-In Users Can Access Another Customer's Records

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

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.

Assessment profile

Ease of attack: Low effort for a valid userThe caller changes a customer or record identifier and relies on the API not checking the resolved object.
Impact: Cross-customer record access

A valid user could read another customer's documents and personally identifiable information (PII).

The user could change or delete those records.
Detection difficulty: Per-object testing requiredTrace each FastAPI permission check through service functions, Cosmos DB and Blob Storage.
Pattern: Object-level authorizationAuthentication succeeds, but authorization is missing for the individual record being requested.

Expected fix Verification

Expected fix Derive record scope server-side FastAPI authentication context: Determine customer and record scope from the signed-in user and trusted server data.

Verification Ignore client-supplied scope Changing a customer or record identifier cannot change the scope derived for the signed-in user.
Expected fix Scope every data query Cosmos DB and Blob Storage adapters: Include the authenticated customer in every record and document lookup.

Verification Prevent unscoped access Database and storage traces show that unauthorized identifiers never reach an unscoped query.
Expected fix Authorize the resolved object FastAPI service and data-access boundary: Recheck the final resource before every read, update, retry and deletion.

Verification Deny cross-customer operations A user assigned to one test customer receives 403 for every operation on another customer's record.
Expected fix Hide unauthorized record existence FastAPI authorization error handling: Return the same public response whether an unauthorized record exists or not.

Verification Prevent record discovery The response does not reveal whether the unauthorized target record exists.
Expected fix Centralize the policy Shared server-side authorization component: Use one owned policy from every FastAPI route and background operation.

Verification Cover every operation consistently All read, update, retry and deletion paths use the same policy, while authorized operations on the user's own records still work.

Illustrative only - not an engagement finding

Some System Actions Do Not Check the User's Role

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

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.

Assessment profile

Ease of attack: Low effort after sign-inA caller invokes a sensitive FastAPI route that checks identity but not the role required for that operation.
Impact: Unauthorized system changes

An ordinary user could change processing behaviour or repeat paid work.

The user could alter or delete records outside their responsibility.
Detection difficulty: Route-by-route reviewMap each FastAPI route through dependencies, service functions and the data layer to its approved Entra ID role.
Pattern: Function-level role enforcementThe React interface may hide an action, but server-side authorization must control whether it runs.

Expected fix Verification

Expected fix Map operations to approved roles Shared server-side authorization policy: Define the Entra ID roles permitted for each sensitive operation.

Verification Deny every unapproved role For every role, each unapproved operation returns 403 without changing data or starting paid work.
Expected fix Enforce roles in the API FastAPI route dependencies: Deny sensitive functions by default, regardless of what the React interface displays.

Verification Prevent interface-only protection Calling the API directly cannot bypass an action hidden or disabled in React.
Expected fix Recheck high-impact operations FastAPI service and data layer: Validate the current role immediately before destructive, irreversible or paid work.

Verification Fail at the final boundary A destructive operation fails when its final permission check is missing, stale or no longer permits the actor.
Expected fix Reject invalid role claims FastAPI Entra ID token validation: Reject missing, unknown or conflicting role claims.

Verification Test every invalid claim state Missing, unknown and conflicting role claims each return 403 before the sensitive function runs.
Expected fix Record the enforced identity Application audit logging: Record the actual actor, role, operation and outcome.

Verification Keep approved work accountable An approved operation completes and records the actual actor, role and outcome.

Illustrative only - not an engagement finding

Users Can Change Record Fields They Should Not Control

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

Business summary

When a user edits a record, the browser sends the changed fields to the API. The user can alter that request with browser developer tools or a separate API client and add fields the screen never showed. If the server saves those extra fields without checking them, the user could change who owns the record, which customer it belongs to, its approval status or its audit history.

Assessment profile

Ease of attack: Only a normal update request is neededThe user adds protected fields to the request sent to the API. The server accepts them because it does not limit which fields may be changed.
Impact: Records can change owner or bypass approval

A user could move a record to another customer, approve their own work or replace who performed the change.

Later processing may trust those false ownership, status or audit values.
Detection difficulty: The screen may still look correctThe hidden change appears only when the review compares the fields accepted by FastAPI with the values written to Cosmos DB.
Pattern: Accept only fields the user may changeEach update action should have a short, explicit list of permitted fields. The server must set customer, ownership, status and audit values itself.

Expected fix Verification

Expected fix Define allowed fields for each update FastAPI request models: Create a separate input model containing only the fields that action is allowed to change.

Verification Confirm permitted changes still work Each permitted field can be changed through the correct endpoint, and Cosmos DB stores the new value.
Expected fix Reject extra fields FastAPI request validation: Reject the entire request when it includes a field that is not listed in the input model.

Verification Block protected input Requests that add ownership, customer, user, audit or protected workflow fields fail and change nothing.
Expected fix Set protected values on the server FastAPI service code: Get customer, user, ownership, audit and workflow values from the signed-in user and trusted server state, not from the submitted request.

Verification Keep ownership and audit values trusted Saved ownership, user and audit values come from trusted server state, never from fields supplied by the caller.
Expected fix Check access before updating Data-access and authorization code: Load the existing record, confirm the signed-in user may change it, then apply the permitted changes.

Verification Deny another customer's updates A request to update another customer's record is denied before any Cosmos DB write.
Expected fix Save all or nothing FastAPI update service and Cosmos DB write: Validate every field and workflow change before saving. If one check fails, save nothing.

Verification Prevent partial changes A rejected request leaves the entire record unchanged.

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

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.
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.
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.
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.
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.

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

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.
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.
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.
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.
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.

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

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.
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.
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.

Third-Party Software and Build Security

The review combines manual analysis of source code and cloud setup files with several security tools. Reviewers check each reported issue against the application's real code paths instead of treating the tool's raw count as the result.

Tool or standard	Purpose
Gitleaks	Detect likely secrets in the current tree and available history.
pip-audit and npm audit	Compare the exact installed Python and JavaScript packages with public security advisories.
Trivy	Check the software used to build a container image and the vulnerabilities inside that image.
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 Files Contain a Reusable Service Key

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

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.

Assessment profile

Ease of attack: Repository or artifact accessA reusable cloud credential remains in source history, build output, caches or deployment files.
Impact: Unauthorized service use

Anyone with a retained copy could use the service outside the application.

Access continues until the credential is revoked.
Detection difficulty: History and artifact scanSearch the current tree, repository history, build artifacts, caches and deployment output without attempting to use the secret.
Pattern: Remove reusable credentialsWorkloads use scoped Entra ID identities instead of service keys stored with source or builds.

Expected fix Verification

Expected fix Revoke and investigate exposure Credential owner and Azure Monitor logs: Revoke and rotate the value, then review its known exposure window for unauthorized use.

Verification Reject the old value The revoked credential no longer authenticates, and the log review covers its full exposure window.
Expected fix Purge every retained copy Azure DevOps repository, artifacts, caches and deployment output: Remove the credential from current and historical material.

Verification Find no surviving copy Secret scans of current files, history, artifacts, caches and deployment output return no match.
Expected fix Use a least-privilege workload identity Container Apps managed identity and Entra ID role assignments: Grant only the service roles the workload requires.

Verification Enforce the approved role boundary The workload operates through managed identity and cannot perform operations outside its approved roles.
Expected fix Remove stored-key fallback Application code and App Configuration: Remove settings and fallback paths that still accept the reusable key.

Verification Run without a stored credential The workload completes its approved work with no stored-key configuration or fallback path.
Expected fix Gate merges and releases on scanning Azure DevOps validation and release pipelines [planned]: Block current files, history or generated artifacts that contain credentials.

Verification Block a planted secret A controlled test credential stops both merge and release.

Illustrative only - not an engagement finding

Unsafe Third-Party Software Processes Uploaded Documents

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

Business summary

The application relies on third-party libraries to open and read uploaded documents. If one of those libraries has a known security flaw, an attacker may trigger it simply by uploading a file designed for that parser. The flaw could run before the application has a chance to reject the document.

Assessment profile

Ease of attack: The attacker supplies a file the library opensA customer-controlled upload reaches an installed Python or JavaScript library whose known flaw applies to that file type and processing path.
Impact: The service can crash or run attacker-controlled code

A malicious document could exhaust memory or processing time, crash the worker or exploit unsafe file handling.

A severe flaw could run attacker-controlled code inside a service that processes documents containing personally identifiable information (PII) or other protected customer data.
Detection difficulty: Check whether uploaded files reach the vulnerable functionConfirm the installed library version, the file types and conditions needed to trigger the flaw, and whether the Container Apps worker sends customer uploads through that code.
Pattern: Prioritize flaws that users can actually reachA release should consider both how serious the published flaw is and whether an uploaded file can trigger the affected code.

Expected fix Verification

Expected fix Upgrade or remove the vulnerable library Python or JavaScript package files: Install a corrected version or remove the library, then lock the approved version used by clean builds.

Verification Confirm a clean build installs the fix A build started from an empty environment installs the corrected library version and not the vulnerable one.
Expected fix Block uploaded files from the vulnerable code until it is fixed Container Apps upload and document-processing worker: Disable the affected feature or reject the relevant file type so customer uploads cannot reach the vulnerable library.

Verification Confirm a test upload cannot reach the flaw A controlled test file is rejected before the vulnerable library runs, while unaffected file types continue to work.
Expected fix Make every clean build install the same package versions Python uv and npm build files: Use one approved lockfile for each runtime and verify downloaded packages against their recorded integrity values.

Verification Match the reviewed package list A clean build installs only the versions recorded in the approved lockfiles and rejects a package whose integrity check fails.
Expected fix Record and scan every library shipped in the release Azure DevOps build and release evidence [planned]: Generate a list of every shipped package and version, then compare it with current security advisories.

Verification Confirm the shipped version The final release package list contains the corrected version, excludes the vulnerable version and passes the advisory scan.
Expected fix Block release while an exploitable library flaw remains Azure DevOps release rules [planned]: Stop release when customer input can reach a known flaw, unless a named owner approves a time-limited exception.

Verification Require an owner and expiry for every exception The release stops without approval. Any exception names its owner, explains why exposure is accepted and expires automatically.

Illustrative only - not an engagement finding

Known Container Risks Do Not Stop a Release

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

Business summary

A container scan may report known vulnerabilities, but it does not prevent deployment. If the release pipeline only saves the report and continues, the same vulnerable container image can still reach production. The pipeline must stop that image or require a named owner to accept the risk for a limited time.

Assessment profile

Ease of attack: The exploit depends on the reported flawThe important control failure is that Azure DevOps allows an image with a known vulnerability or missing proof of origin to continue toward production.
Impact: Known risk reaches production

A container with a known exploitable flaw could be deployed unchanged.

The team may be unable to prove that the deployed image is the one built from reviewed source and scanned.
Detection difficulty: Follow one image from build to deploymentConfirm which image entered Azure Container Registry, which scan result belongs to it, who accepted any exception and which identity deployed it.
Pattern: Approve and deploy the same container imageThe source, build record, package list, scan and deployment must all name the same fixed image fingerprint, called a digest.

Expected fix Verification

Expected fix Deploy the exact image that was approved Azure Container Registry and Container Apps deployment [planned]: Release an image by its fixed digest rather than by a reusable name or tag.

Verification Move the approved image without rebuilding it The approved digest is deployed to the target environment without creating or substituting another image.
Expected fix Attach source and scan results to that image Azure DevOps build record [planned]: Link the reviewed source revision, list of shipped packages and vulnerability scan to the image digest.

Verification Confirm every record names the same image The source revision, build, package list, scan result and deployment all identify the same digest.
Expected fix Stop images that violate the approved risk rules Azure DevOps release gate [planned]: Block an image when a vulnerability is serious enough and the running application can reach the affected code.

Verification Confirm a known violation stops deployment A test image that violates the release rules cannot be deployed.
Expected fix Require an owner and expiry for every exception Azure DevOps release approval [planned]: Require a named owner, a written reason for accepting the risk and an automatic expiry date.

Verification Keep every accepted risk visible An exception names its owner and reason, remains attached to the release record and expires automatically.
Expected fix Allow only the release pipeline to deploy images Azure DevOps pipeline managed identity [planned]: Give deployment permission only to the controlled pipeline and only for an approved digest.

Verification Block manual or unauthorized deployment A person or service identity outside the controlled pipeline cannot deploy an image.

Relationship to the Azure Review

This review leads with application behaviour and object authorization: what the code allows, which records a caller may use and how untrusted AI or file content is handled. The Azure review proves the companion boundary in deployed configuration, cloud identity, networking and monitoring.

See how the Azure review verifies the deployed cloud boundary.

What You Are Reading

This demonstration shows what a Threat Tribunal engagement delivers and how each chapter uses evidence.

This site contains no client names, identifiers, resource names, source paths, or any combination of details that could reconstruct a client environment.

Cross-reference links lead only to fictional examples created for this demonstration. They never lead to client code, Azure resources or engagement test output.

Limitations

This report explains what the review covers, how it works and what it checks. It does not include client findings, ratings, evidence, fix status or current cloud settings.

It is not a penetration test, certification or assurance opinion. Inclusion of a topic means it was assessed, not that a finding existed.

Public References

Application and AI Security Review · Full Edition

Part of a Threat Tribunal demonstration review.

Back to the chaptered edition