Security Bug Report

Before you submit: do not include real passwords, full tokens, production personal data, payment-card data or customer secrets. Mask sensitive values (keep only what proves the issue). Use controlled test accounts and approved environments.

Title

One clear sentence: who can do what they should not. E.g. "Normal user can access another user's invoice by changing the invoice ID."

Summary

A short paragraph describing the issue and why it matters.

Environment

• Environment (test / staging) and build / version
• Browser / OS / client, if relevant

User role / account used

• The test account and its role (e.g. read-only user, User A vs User B).

Affected feature / page / API

• Page URL or API endpoint and method.

Preconditions

• Anything that must be true first (logged in as X, object owned by Y).

Steps to Reproduce

1. First action
2. Second action
3. Continue until the issue is shown…

Expected Result

What the control should do (e.g. "API returns 403").

Actual Result

What actually happens (e.g. "API returns 200 with User B's data"). Mask sensitive values.

Security Impact

What could go wrong: data exposed, action performed, who is affected.

Business Impact

Customer, compliance or financial impact in plain terms.

Evidence

• Request/response status and relevant body (masked)
• Screenshots of the UI and network panel (masked)
• Timestamp and correlation/trace id

Data exposed or action performed

Exactly what was accessible or what action succeeded — described, not pasted in raw.

Suggested severity

Critical / High / Medium / Low — with a one-line justification.

Suggested priority

P1 / P2 / P3 — based on impact and reach.

Scope

What you tested and, importantly, what you did NOT test (stay within the agreed scope).

Notes for escalation

Who should be looped in (security / backend / DevOps) and why this needs attention.

---

Tip: report the finding, not an exploit. Describe the impact and provide masked evidence. If confirming the issue would require going beyond your agreed scope, stop and escalate instead.

Security Bug Report

Title

Normal user can access another user's invoice by changing the invoice ID

Summary

A standard (non-admin) user can view another user's invoice by changing the numeric invoice ID in the URL. The server returns the invoice without checking ownership. This is a broken access control (IDOR) issue exposing other customers' billing data.

Environment

• Staging, build 2026.06.03-rc2
• Chrome 126 / macOS

User role / account used

• User A — standard user (test account qa-user-a@example.test)
• Target data belongs to User B (test account qa-user-b@example.test)

Affected feature / page / API

• GET /api/invoices/{id} (also reachable via /billing/invoices/{id} in the UI)

Preconditions

• Logged in as User A
• An invoice owned by User B exists (id 10532)

Steps to Reproduce

1. Log in as User A and open one of your own invoices, e.g. /billing/invoices/10487.
2. Change the ID in the URL to 10532 (an invoice owned by User B).
3. Observe the response.

Expected Result

The API returns 403 Forbidden (or 404) — User A does not own invoice 10532.

Actual Result

The API returns 200 OK with User B's invoice, including their name, billing address and amount. (Values masked in evidence.)

Security Impact

Any authenticated user can enumerate invoice IDs and read other customers' billing details — a confidentiality breach affecting all customers with invoices.

Business Impact

Exposure of customer billing data; potential privacy/compliance violation and loss of trust.

Evidence

• Request: GET /api/invoices/10532 with User A's session
• Response: 200 OK, body contains another customer's fields (name and address masked: J••• D•••, ••• Main St)
• Screenshot of the network panel (masked) attached
• Timestamp 2026-06-03 14:22 UTC, trace id a1b2••••

Data exposed or action performed

Read access to another user's invoice record (identity and billing fields). No data was modified.

Suggested severity

High — cross-user data exposure reachable by any authenticated user.

Suggested priority

P1 — affects all customers and exposes personal/billing data.

Scope

Tested object-level access on the invoices endpoint only, with two controlled test accounts on staging. Did not test other endpoints or attempt any modification.

Notes for escalation

Please loop in the billing/backend team and security. The fix is a server-side ownership check on GET /api/invoices/{id}; the same pattern should be reviewed across related billing endpoints.

---

More good title examples

• Password reset link can be reused after password change
• Read-only user can update record using API request
• Expired shared file link still allows download