- Ya
- 26 Agosti 2026, 05:17 UTC
- Mwandishi
- Kamo
- Ahadi ya
- 6a6662a
Every endpoint that accepted a VIEW_OWN_* right as an OR-alternative loaded its record by primary key alone, never checking who it belonged to: getSubscription, getSubscriptionOrder, getSubscriptionEvents, getInvoice, getSubscriptionAgreement and getSubscriptionAgreementHtml. orgId was read for the 401 and never used again. A caller holding only the customer right could read any subscription, order, invoice or agreement on the platform given its UUID. Endpoints that only accept the VIEW_OWN_* right alone (getMySubscriptions, getMySubscriptionOrders, getMyInvoices, getMyAgreements) already derived memberId from the session and were left untouched. acceptAgreement already passes memberId to the service and was left untouched for the same reason, though the service itself does not verify the accepter owns the underlying subscription -- that gap lives in SubscriptionService, out of this file's reach, and is noted for follow-up rather than fixed here. SubscriptionRecordDTO, SubscriptionOrderDTO and SubscriptionInvoiceDTO expose customerMemberId directly, so those four endpoints filter after the fetch by comparing it to the caller's session memberId. SubscriptionAgreementDTO exposes neither a member nor a direct owner field -- only organizationId and the uid of the subscription it belongs to -- so the two agreement endpoints resolve ownership by loading that subscription and checking its customerMemberId instead. 404, not 403, on an ownership mismatch: a 403 would confirm the UUID names a real record in another tenant, which is itself a disclosure. Named as the counter-example in the program design's own invariant 6.