Cross-account invoice access
- Target
- demo-store.example
- Scope
- Selected invoice access flow; two approved dummy customer accounts.
- Excluded
- Payments, third-party services, destructive testing, and unrelated application areas.
- Assessment limits
- One fictional workflow. This preview does not represent a complete audit or a real test result.
One account could read another account’s invoice.
The invoice endpoint checked that a user was signed in, but did not check that the requested invoice belonged to that user. In this fictional example, this exposed a dummy invoice across the customer boundary.
- Create two authorized dummy accounts, A and B, each with its own dummy invoice.
- While signed in as A, request the approved dummy invoice belonging to B.
- Observe that the application returns B’s dummy invoice instead of denying access.
Test-account identifiers, invoice ownership, request time, and a redacted response containing only dummy data. No real customer information is used.
A similar weakness in a real application could expose private invoice information between customers. The rating depends on the data, access requirements, reach, and validated scope. “High” is illustrative here; a real report explains its rationale.
Enforce invoice ownership or an explicitly permitted role on the server for every invoice request. Check authorization before returning data, and add regression checks for allowed and denied cross-account access.
A fix needs another check.
A developer’s fix submission starts a retest. The original cross-account request must be denied while authorized access still works. The retest records the version, scope, date, evidence, and any remaining limits.
Reported: the dummy cross-account access was demonstrated. No fix has been assessed.
This interactive example changes this preview only. It does not update an engagement.Your deliverable follows the agreed engagement scope. A limited initial check and a full assessment have different coverage and depth.
Discuss your website ↗