Use these fix ticket fields
Give the engineer a small, safe test setup: seeded account, role, object, route, and redacted request. State the broken authorization rule in one sentence. Separate observed behavior from the tester’s guess about the root cause.
| Item | Check or owner | Evidence |
|---|---|---|
| Precondition | Role, tenant, and state | Set up safe test data |
| Reproduce | Minimum requests | Attach redacted trace |
| Expected rule | Who should be allowed? | Name authorization owner |
| Retest | Original and variant | Record tested build |
Test and retest
Write a failing test that follows the reported sequence and a positive test for the allowed user. Ask the fix owner to check sibling routes using the same rule. The reviewer reruns the original case on the built release and records the result in the ticket.
Evidence to keep
The ticket should also list impact in plain terms. “A support role can read a payout token from another tenant” tells the owner what matters. “Missing filter in repository method” is only a possible cause. Keep a minimal trace and a rule statement at the top, then put longer logs behind a restricted link. If a reviewer needs a customer record to reproduce, replace it with seeded data first. That lets engineers fix the issue without copying private data into issue trackers.
Hand over a fix engineers can reproduce
Synthetic finding: a support user can download another customer’s statement by changing the account ID. Give engineering two seeded accounts, the support role, the exact request, the expected denial, and the trace ID. Keep real customer data out of the ticket. Name the failing rule in one line: the statement API must check account access on the server before fetching the file.
Add a success test for an allowed account and a failure test for the other account. Include the file-storage path, cache behavior, and every route that can fetch the same statement. A developer can then fix a shared authorization decision rather than patch one button. The handoff is complete when a reviewer can run both tests on the deployed build and see the file was never returned or cached for the forbidden user. OWASP’s authorization guidance calls for server-side checks on each request.
Make the ticket runnable
A complete synthetic ticket reads: F-17; support role S-1; seeded accounts A and B; GET statement for B while signed in under A; expected denial before file lookup; observed B’s PDF returned; trace T-9; build R-18. Attach reset steps, a redacted request, and the exact rule owner. Keep the full PDF out of the ticket; use a fake statement with a visible seeded identifier.
Add two acceptance cases. A role with explicit access to A can download A’s statement. S-1 without access to B receives no file, cached response, signed link, or export job for B. List the direct route, bulk export, storage access, and cache paths that use the same rule. If support should never read a payment token, the allowed case must test its proper service role instead of granting support new token rights.
Ask engineering for the shared guard changed, affected components, migration needs, and rollout ID. The reviewer then links API and worker builds to the observed denial. Keep cause guesses in a separate note: the fix can be a tenant filter, cache-key repair, or file authorization check while the broken business rule stays the same.