fix: gate shop origin and pin pay

[ben-kaufman]

Description

Shop checkout only accepts Bitrefill payment requests, and QuickPay now honors PIN protection.

1. Accept shop payment_intent messages only from Bitrefill HTTPS origins (bitrefill.com and subdomains).
2. Block main-frame and window.open navigation off Bitrefill; CDN subresources stay allowed.
3. Skip QuickPay when PIN-for-payments is on, so confirm can ask for PIN.

VulnHunter 01b findings 02 (shop WebView any-origin payment_intent) and 03 (QuickPay skips PIN). iOS lock already unmounts the main tree, so there is no queued-scan work here.

Companion Android PR: synonymdev/bitkit-android#1158

Linked Issues/Tasks

VulnHunter 01b findings 02 and 03.

Screenshot / Video

N/A, security behavior only.

QA Notes

• 1. Shop → gift card → Bitrefill checkout → payment_intent: Send Confirm or QuickPay opens with the invoice.
• 2. Shop WebView stays on Bitrefill; a main-frame jump off Bitrefill does not load.
• 3. Settings → PIN on + PIN for payments + QuickPay on → scan a small LN invoice: Confirm opens, not QuickPay; swipe asks for PIN or biometrics.
• 4. regression: PIN off or PIN for payments off + QuickPay on → scan a small LN invoice: QuickPay still opens.

Unit tests: ShopOriginTests.swift, PaymentNavigationHelperTests.swift.

Made with Cursor

[greptile-apps]

Greptile Summary

The PR restricts Bitrefill checkout messages and top-level navigation to trusted HTTPS origins and disables QuickPay when payment PIN protection is enabled.

• Adds centralized Bitrefill host and message-origin validation.
• Applies navigation restrictions through the shared shop WebView, inadvertently blocking the existing BTC Map caller.
• Routes PIN-protected payments through confirmation and adds focused unit tests.

Confidence Score: 4/5

The PR should not merge until the Bitrefill-only navigation policy is scoped so that Shop Discover can still load BTC Map.

The shared WebView cancels Shop Discover's initial btcmap.org main-frame request because the new delegate allows only Bitrefill HTTPS origins.

Files Needing Attention: Bitkit/Components/ShopWebView.swift

Important Files Changed

Filename	Overview
Bitkit/Components/ShopWebView.swift	Adds origin checks for messages and navigation, but the unconditional Bitrefill policy breaks the shared WebView's BTC Map caller.
Bitkit/Utilities/ShopOrigin.swift	Adds HTTPS Bitrefill host validation and sender-origin filtering with appropriate apex and subdomain matching.
Bitkit/Utilities/PaymentNavigationHelper.swift	Prevents QuickPay selection when both PIN and payment-PIN protection are enabled.
Bitkit/Views/Shop/ShopMain.swift	Rejects empty payment URIs before handing trusted checkout messages to payment parsing.
BitkitTests/ShopOriginTests.swift	Covers host and bridge-script validation but does not exercise the shared WebView navigation policy.
BitkitTests/PaymentNavigationHelperTests.swift	Covers every boolean combination of the new payment-PIN gate.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[ShopWebView initial navigation] --> B{Main frame?}
    B -- No --> C[Allow subresource]
    B -- Yes --> D{Bitrefill HTTPS origin?}
    D -- Yes --> E[Allow checkout]
    D -- No --> F[Cancel navigation]
    G[Shop Discover: btcmap.org] --> A
    F --> H[BTC Map does not load]

Loading

_{Reviews (1): Last reviewed commit: "fix: gate shop origin and pin pay" | Re-trigger Greptile}

[ovitrif]

Looks good. Shop checkout rejects payment_intent messages from non-Bitrefill origins, and QuickPay no longer bypasses PIN-for-payments.

[ovitrif]

Simulator QA on to.bitkit @ 9c215ea (iPhone 16, iOS 18.5). PIN 1234, QuickPay on, spending 97316 sats after a Blocktank transfer.

• 1. Shop → Gift Cards → Amazon.fr €100 cart → Checkout (email step). Did not submit. Shop talks to real embed.bitrefill.com, so checkout would emit a mainnet invoice a regtest wallet cannot act on.
• 2. Gift Cards → eSIMs, product, checkout, and Help stayed on Bitrefill. Privacy Policy stayed on Bitrefill (Bitrefill 404 page). Did not find a live off-Bitrefill main-frame URL to block.
• 3. PIN on + PIN for payments on + QuickPay on → 500-sat LN invoice: Confirm opened, not QuickPay. Swipe To Pay asked for PIN.
• 4. PIN on + PIN for payments off + QuickPay on → 600-sat LN invoice: QuickPay opened. The payment itself failed (Failed to send the given payment) because the invoice was on a different regtest than this wallet; the check was that QuickPay opened, not that it settled.