Threat Tribunal

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
  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.

Related illustrative findings: privileged application actions; cloud admission and Microsoft Entra ID in the Azure review.

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
  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.

Related illustrative findings: customer record boundaries; protected record fields.

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
  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.

Related illustrative findings: customer record authorization; record lifecycle in the companion review.