[#745] Add CSP headers for WalletConnect and Farcaster

[realproject7]

Summary

• Add Content-Security-Policy via next.config.ts async headers
• connect-src: allows https: and wss: for WalletConnect relay, Supabase, Alchemy, Farcaster SDK
• frame-ancestors: allows Farcaster and Base app embedding
• Permissive baseline (https:) to avoid breaking existing integrations while establishing CSP
• img-src: allows data:, blob:, https:, http: for wallet icons and IPFS content

Fixes #745

Test plan

• No CSP errors in Chrome console for WalletConnect domains
• WalletConnect wallet option can initiate connection
• Wallet icons load in RainbowKit modal
• Farcaster Mini App embedding still works
• Supabase, Alchemy, IPFS connections still work
• npm run build passes

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
plotlink	Ignored		Apr 2, 2026 10:01am

[project7-interns]

T2b REQUEST CHANGES — CSP is over-broadened, which the ticket explicitly asked to avoid.

Issue 1: connect-src 'self' https: wss: is a no-op
The ticket asks to "add walletconnect.com to connect-src without over-broadening." Blanket https: wss: allows any origin — this doesn't restrict anything. Please whitelist specific domains:

• wss://relay.walletconnect.com wss://relay.walletconnect.org
• https://.walletconnect.com https://.walletconnect.org
• Your Supabase, Alchemy, Farcaster, IPFS endpoints

Issue 2: script-src 'unsafe-eval' 'unsafe-inline' https: provides zero XSS protection
unsafe-eval + unsafe-inline defeats the purpose of CSP for scripts. Next.js needs unsafe-inline for dev, but unsafe-eval should be avoided. Consider using nonces or at least dropping unsafe-eval in production.

Issue 3: default-src blanket https:
default-src with https: makes most specific directives redundant since they fall back to this.

The frame-ancestors directive is good and specific. Please apply the same specificity to connect-src at minimum — that's the core ask of the ticket.

[project7-interns]

Verdict: REQUEST CHANGES

Summary

This unblocks WalletConnect by adding a site-wide CSP, but the policy is much broader than the ticket asked for and does not preserve meaningful restrictions.

Findings

• [high] The new CSP uses protocol-wide allowlists like https: and wss: for connect-src, plus similarly broad default-src, frame-src, and img-src http: rules. Issue #745 explicitly asked to add the specific WalletConnect domains without over-broadening the policy. As written, any injected code can still talk to arbitrary HTTPS/WSS endpoints, so the new header does not satisfy the ticket's "other CSP protections still in place" requirement.
  • File: next.config.ts:12
  • Suggestion: narrow the policy to the concrete WalletConnect domains from the issue (and any already-required app origins), rather than using protocol-wide https:/wss: fallbacks and http: for images.

Decision

Requesting changes because the current CSP is too permissive for a security-policy fix and does not match the issue's targeted-domain requirement.

[project7-interns]

T2b APPROVE — re-reviewed after CSP tightening. Significantly improved:

• default-src 'self' — restrictive baseline ✓
• connect-src now whitelists specific domains: WalletConnect (4 origins + relay), RPC providers, Supabase, Farcaster/Neynar, price APIs, IPFS, Vercel analytics ✓
• frame-src and frame-ancestors both specific ✓
• style-src and font-src scoped to Google Fonts ✓
• img-src 'self' data: blob: https: — broad but acceptable for wallet icons from various sources
• script-src still has unsafe-eval/unsafe-inline (Next.js requirement) but no blanket https: ✓

Well-organized with comments per domain group. This is a proper CSP that addresses the ticket.

[project7-interns]

Verdict: APPROVE

Summary

The CSP is now narrowly scoped to explicit WalletConnect and app-required origins instead of protocol-wide https:/wss: allowlists. The specific WalletConnect domains from issue #745 are covered, and the previous over-broadening concern is resolved.

Findings

• None.

Decision

Approving because the review blocker is addressed and I do not see a remaining code-level mismatch against the ticket.