Check that one customer cannot open another receipt
The receipt screen fetches an order by URL ID. Add an authorization regression covering both the page and its backing endpoint with two synthetic customer accounts.
- Focused work estimate
- 1h 30m + prerequisites
- Priority in the scenario
- High
- Engineering practice
- Authorization testing · API testing · Privacy
Estimated field mix
- Quality engineering60%
- Security40%
Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence.
Review it, then add it to your workspace.
The board opens an editable draft; nothing is saved until you confirm it. Sign-in and workspace permissions apply, and Demo boards remain ephemeral.
Project context
A small commerce team has happy-path browser tests but still ships rounding and retry defects. Model a fictional shop using synthetic products, a local payment double, and explicit cart rules before adding regression coverage.
Setup prerequisites
- Create or provide a local checkout fixture application.
- Model products, tax rules, inventory, and a payment-provider double using synthetic data.
Preceding work
Complete these dependencies, or supply their agreed outputs before taking this ticket.
Acceptance criteria
- An owner can load their receipt with the expected line items.
- Another customer and an anonymous session cannot retrieve receipt details by changing the order ID.
- Denied responses and browser artifacts contain no customer address or item details.
Implementation constraints
- Treat order IDs as discoverable; obscurity is not the access rule.
Verification to include
- Open the same order using owner, second-customer, and logged-out contexts.
- Attempt the direct receipt API request and inspect its body for leaked fields.
Deliverables
- Receipt access matrix and browser/API denial tests
Rollout and recovery
Make the access checks a required checkout gate; quarantine artifacts if a regression exposes fixture-sensitive fields.
Value of the work
For the engineer: Practice risk-based test selection, stable browser automation, and diagnosis of intermittent failures.
For the team: Review whether a test suite catches business regressions and explains failures without creating noisy release gates.
Evidence boundaries
Outcome Evidence: Tests, patches, and runbooks are requested deliverables. They become Outcome Evidence only through a qualified Mission and immutable Evidence IDs.
Ownership Evidence: Independent adaptation must be observed under a declared verification policy and cite immutable Evidence IDs. Completing a planning ticket establishes no Ownership Evidence.