Veridian Commerce checkout and merchant portal

GET /v2/invoices/{invoice_id} on api.veridian.example

Handler: services/billing/handlers/invoice.go:118

Authenticate as any shopper account created through public signup. Place one order to obtain a valid invoice identifier, then decrement it.

# 1. our own invoice, as shopper_a — expected
GET /v2/invoices/80419 HTTP/1.1
Host: api.veridian.example
Authorization: Bearer   redacted  

HTTP/1.1 200 OK
{"invoice_id":80419,"customer_id":5512,"name":"Test Shopper A", ... }

# 2. decrement the identifier — not our invoice
GET /v2/invoices/80418 HTTP/1.1
Host: api.veridian.example
Authorization: Bearer   redacted  

HTTP/1.1 200 OK
{"invoice_id":80418,"customer_id":4471,
 "name":"        ","gstin":"       ",
 "ship_to":{"line1":"          ","city":"Pune"},
 "card_last4":"    ","total":"14,990.00"}

Specimen capture. Personal fields are masked in this published copy; the client copy carries them in full.

The handler loads the invoice by primary key and returns it. There is no check that the invoice belongs to the authenticated customer. Authentication is verified by middleware, which is why this was not caught: the request is authenticated, it is simply not authorised.

// services/billing/handlers/invoice.go:118
inv, err := h.repo.GetInvoice(ctx, invoiceID)
if err != nil { return notFound(w) }
// no ownership check between load and render
return json.NewEncoder(w).Encode(inv)

Any person who can complete public signup can read the billing record of every customer in the platform. Identifiers are sequential, so enumeration is trivial and requires no special tooling. At the time of testing the invoice table held approximately 80,400 rows.

Exposed per record: customer name, full delivery address, order contents, order value, last four digits of the payment instrument, and for business buyers the GST registration number. For a consumer marketplace this is a reportable personal data breach, and the combination of name, address and purchase history is directly usable for targeted fraud against your customers.

CVSS 3.1 base scores this 6.5 — AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N — because it requires privileges and affects confidentiality only. That score is calculated without knowing what the data is or how many records exist.

We rate it 9.1. The privilege required is a free account anyone can create in under a minute, which is not meaningfully a privilege. The identifiers are sequential, so the whole table is reachable. We disagree with the base score and have recorded both so your auditor sees the standard calculation and your engineering lead sees the number that should decide priority.

Scope the query to the authenticated principal rather than filtering after load. Change the repository call at invoice.go:118 to take the customer identifier from the session context:

inv, err := h.repo.GetInvoiceForCustomer(ctx, invoiceID, auth.CustomerID(ctx))
if err != nil { return notFound(w) }

Return 404 rather than 403 so the endpoint does not confirm which identifiers exist. The same pattern appears at orders.go:74 and shipments.go:91; both are recorded as CL-0147-02 and should be fixed in the same change. Longer term, move ownership scoping into the repository layer so a handler cannot load a record it is not entitled to.