See what a useful security deliverable looks like

Engagement boundaries

Fictional target: sample.invalid. Example assessment authorized for test tenants A and B, an isolated staging API and synthetic records only. Production infrastructure, user data, denial-of-service testing and unrelated hosts are out of scope.

• Test window and points of contact agreed in writing
• Two seeded test accounts with different tenants
• Data minimization and immediate stop conditions in the rules of engagement

Observation and impact

In the fictional handler GET /api/documents/{documentId}, the caller is authenticated, but the record is fetched using only the client-supplied identifier. The service does not check the document's tenant or allowed actions before returning it. An attacker who learns another document ID could read data outside the authorized tenant. The severity assumes the endpoint exposes sensitive records; real severity depends on exploitability and impact.

Evidence package

A report would include redacted request IDs, two synthetic principal identities, a test-owned document identifier, expected response (403 or privacy-preserving 404), actual unauthorized 200, timestamp and environment. No credentials or third-party data would be reproduced in the deliverable.

• Expected: tenant A cannot access tenant B document
• Illustrative observed result: 200 OK with a synthetic tenant B record
• Evidence confidence: demonstrated in the fictional example, not verified against a real customer

Remediation and retest

Move authorization into the object read path: derive the principal and tenant from server-verified identity, filter the query by authorized tenant, and check the action policy before returning or mutating a record. Add cross-tenant read/write/delete tests, audit sibling endpoints and batch exports, and verify the corrected invariant cannot be bypassed by changing path or body IDs.

• Owner: API engineering
• Priority: urgent if confirmed on sensitive production records
• Retest gate: same synthetic cross-tenant request consistently denied and regression tests green

Reviewed scope

A fictional mobile account-management flow and its API endpoint. Review input includes a small illustrative handler, its authentication middleware and test fixtures. No actual customer source code is shown.

Risky implementation

The request body contains isAdmin and accountId values and the handler treats isAdmin=true as permission to edit the selected account. The UI hides the control for ordinary users, but a custom client can send the same request. The trust violation occurs when a caller-controlled field becomes a server-side authorization fact.

Proposed code correction

Ignore client claims of role or tenant authority. Load the authenticated principal from a verified session, retrieve the target account through an authorized repository query, and enforce a server-owned policy for the exact action. Deny unrecognized roles by default and document legitimate delegation or support-admin exceptions separately.

Test and delivery expectations

The review output should name the affected code location, explain the exploit path and provide a minimal test plan rather than only a severity label.

• Caller A cannot update caller B's account by changing accountId
• isAdmin=true in the payload does not grant new permissions
• Legitimate admin operations are independently authorized and audited
• Authorization tests run in CI and are revisited after schema or role changes

System and assets

Components: iOS and Android apps, authentication service, session store, customer data API, recovery service and security telemetry. Assets: account access, refresh credentials, signing keys, recovery factors and sensitive records. The device and its network requests are untrusted inputs even when the app is distributed through an official store.

Trust-boundary map

Boundary 1: client app to internet API, where identity and request integrity are established. Boundary 2: API to authorization/data layer, where account and object access must be enforced. Boundary 3: recovery service to session store, where changing credentials must revoke previous authority. Boundary 4: build pipeline to production deployment, where artifact provenance and deploy identity matter.

Threats and mitigation choices

Threat 1: stolen refresh token replay—rotate tokens with family/reuse detection and bounded server-side lifetime. Threat 2: account recovery downgrade—require independent recovery proof and invalidate related sessions. Threat 3: cross-account API access—authorize every object and action on the backend. Threat 4: forged device state—treat attestation and integrity verdicts as verified risk signals, not as identity.

• Assumption to validate: all privileged actions share the same server-side policy
• Open question: acceptable outage behavior when attestation is unavailable
• Owner decision: which actions must fail closed
• Residual risk: a recognized genuine device can still be used by a compromised account

Validation plan

Test revoked sessions, concurrent refresh, stolen-token reuse, changes to object identifiers, an integrity token bound to a different action, and a recovery flow that attempts to retain old sessions. Each test has a recorded expected server response, not just a UI assertion.

Triage

Block the affected sensitive read path if a real exploit is confirmed and immediate authorization correction is not possible. Confirm the scope of exposed objects, protect evidence and avoid collecting excess personal data. Assign an incident and engineering owner.

Implementation sequence

Phase 1: define a principal-to-object authorization invariant and enforce it at data access. Phase 2: remove client-supplied role authority from endpoints. Phase 3: add multi-tenant negative tests across read/write/export paths. Phase 4: review analogous routes and caches. Phase 5: deploy with monitoring, rollback conditions and a controlled retest.

• Change owner: backend/API team
• Review owner: security engineer
• Release owner: service operations
• Dependency: seeded cross-tenant fixtures and documented role semantics

Acceptance criteria

Unauthorized cross-tenant requests fail on every identified endpoint; legitimate same-tenant operations continue to succeed; audit logs contain safe, correlatable reason codes; the PR links to regression tests and reviewer sign-off; and retesting confirms the original failure is no longer reproducible.

Residual risk and follow-up

Review token lifetime, delegated administrative access, asynchronous jobs and data already exported. Record exceptions and schedule verification of any deferred controls. Closing a ticket is not evidence of closure unless the original exploit path is retested.