fix: validate and restrict LNURL request targets

[reneaaron]

Describe the changes you have made in this PR

LNURL endpoints supplied by a website (via window.webln.lnurl, or an lnurl found on the page) are requested from the extension's privileged background/prompt context, which holds broad host permissions. This restricts which targets those requests may reach.

• New src/common/lib/lnurlValidation.ts:
  • assertAllowedLnurlUrl(url) — requires https: (allows http: only for .onion) and rejects loopback, private (RFC1918), CGNAT, link-local, cloud-metadata, multicast and reserved targets. IPv6 literals are expanded before classification, so IPv4-mapped (::ffff:127.0.0.1), IPv4-compatible and NAT64 (64:ff9b::) forms are recognised after the URL parser re-serialises them as hex; fe80::/10, fc00::/7 and fec0::/10 are covered.
  • assertAllowedCallbackUrl(callback, lnurlUrl) — a callback may stay on the origin of the LNURL that produced it; otherwise it must satisfy the same restrictions. Cross-host callbacks (common for lightning addresses) keep working.
  • lnurlGet(url, config, opts) — an axios GET that validates the target and, for website-supplied LNURLs, does not follow redirects.
• Applies the guard to the detail request (common/lib/lnurl.ts), the lnurl-auth login request (actions/lnurl/auth.ts) and the pay / withdraw / channel callbacks.
• getDetails takes a userInitiated flag. Send and LNURLRedeem set it, so an LNURL the user pasted or scanned — which may be a self-hosted service on a local network over http — keeps working and may follow redirects. The website-driven paths are unaffected.
• Failed detail requests report a generic message instead of relaying the upstream response text; the LNURL service's own status: "ERROR" reason is still shown, since the endpoint host has been validated.

Behaviour changes worth noting

• Website-supplied LNURLs must be https (except .onion) and cannot point at a local/private address. User-pasted LNURLs are unrestricted.
• Redirects are not followed for website-supplied LNURLs. Per-hop re-validation is not possible in a browser (a manual redirect is opaque, with no readable Location), so they are refused rather than re-checked. Worth a second opinion: if a provider redirects /.well-known/lnurlp/<user> to another host, paying that address from a website would now fail. User-initiated payments still follow redirects.
• A lightning address that cannot be reached now says so, instead of claiming the address is invalid.

Tests

• src/common/lib/__tests__/lnurlValidation.test.ts — host classification, plus URL-level assertions that go through the WHATWG parser (the form the validator actually receives), and callback origin handling.
• The jsdom test environment now provides fetch/Request/Response and the matching abort primitives from one realm, so the axios fetch adapter (and msw) work under test.

yarn lint, yarn tsc:compile and yarn test:unit all pass (76 suites, 209 tests, 2 pre-existing skips).

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}