Application and Service Boundaries

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.

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.

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

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

Application Review · Control Domain 3 of 5 · Public Edition

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

Report overview