AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Moderate 64 Bitcoin

Unify GetStoreDataOrNull/GetInvoiceDataOrNull

Public commit record

What the developer wrote

Authored by Nicolas Dorier

35/100 · Opaque
Unify GetStoreDataOrNull/GetInvoiceDataOrNull
✓ Descriptive subject! No meaningful explanatory body
The short version

What changed, and why it matters

This commit is a large internal cleanup that renames and unifies how BTCPay Server looks up store, invoice, app, and payment-request data from the HTTP request context. The main visible change is that many controllers stop manually checking the database for a store/invoice and instead rely on data that an authorization filter already placed in the request context. The commit also adds route-to-store mappings for paymentRequestId and pullPaymentId, and adds a new test that verifies a user with view-only invoice permission cannot read an invoice belonging to a different store. While the change is mostly defensive, it is also risky: if the authorization filter ever misses a route or a controller action is reachable without the filter, the controller may assume it has a valid store/invoice when it does not, which could lead to null-reference crashes or, in the worst case, cross-store data access.

Recommended action

Treat this as a security-sensitive refactoring. Review that every affected controller/action is still covered by the authorization pipeline that populates BTCPAY.STOREDATA/BTCPAY.INVOICEDATA/BTCPAY.APPDATA/BTCPAY.PAYMENTREQUESTDATA. Pay special attention to actions that removed explicit null checks and now call GetStoreData() (throwing) or GetStoreDataOrNull() without fallback. Run the new GreenfieldAPITests regression and add similar cross-store/cross-resource negative tests for payment requests, pull payments, apps, and webhooks. Consider adding controller-specific filters for plugin routes rather than relying solely on the global SetContextFilter, as the commit comments suggest.

Security signals we found

01

Authorization-context lookup consolidation across Greenfield and UI controllers

02

Removal of explicit per-controller store/invoice existence checks in favor of filter-populated context

03

New route-value-to-store-id mappings for paymentRequestId and pullPaymentId

04

Added regression test for cross-store invoice access via Greenfield API

05

Change from throwing helpers to nullable helpers in many UI controllers

06

Potential for null-store dereference if SetContextFilter does not run or misses a route

Risk score

Why this scored 64/100

Our methodology →
Potential impact 18/30
Exploitability 15/25
Stealth signal 10/15
Affected reach 12/15
Confidence 6/10
Evidence quality 3/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.