Web3 application penetration testing for Wallet Connectors: Common Attack Paths

A Quick Guide for Decision-Makers on Penetration Testing Wallet Connectors in Modern Web3 Stacks

This guide is all about helping you navigate the world of penetration testing for wallet connectors in today’s web3 landscape. We’ll break down the specific attack paths you need to keep an eye on, highlight what you should test, and recommend some forward-thinking controls for 2025 that can significantly lower risks like draining, phishing, and supply chain issues.

Why wallet connectors are today’s highest‑leverage pentest target

Wallet connectors are like the gatekeepers between your users and on-chain actions. In 2024-2025, things took a turn: attackers started moving away from hacking contracts and instead focused on breaking in through the front door using these connectors. They exploited over-privileged sessions, used tricky signatures (think Permit/Permit2), hijacked deep links, unleashed malicious mobile apps, and even took advantage of compromised UI libraries. It got pretty wild--drainer kits alone made off with about $494 million in 2024, hitting around 332,000 addresses. Toolkits like Angel Drainer and AngelX even automated some sneaky tactics across EVM, TON, and Tron networks. If you’re putting together a security program, make sure to prioritize a thorough pentest of your connector surface. Check out more on this here: (drops.scamsniffer.io).

Just a heads up: WalletConnect, the go-to connector network, has officially rebranded as Reown. They’ve rolled out a new Verify API that connects wallet requests to the actual domain of the dapp. This means wallets can now display “trusted/mismatch/threat” statuses right in the signing UI. So, make sure your test plans take Verify into account and check that your app is set up to work with it. Check out more details here.

---

Attack path 1 -- Supply‑chain compromise of connector libraries

The Ledger Connect Kit incident on December 14, 2023, is a prime example of how things can go sideways. A compromised NPM/CDN build got into a bunch of dapps, tricking users with malicious signing prompts that ended up draining their funds until every site managed to update the library. This all started with a former employee’s NPM account being hacked, leading to the release of malicious versions (1.1.5 to 1.1.7) that caused a staggering ~$484k in losses in just a matter of hours. Moving forward, pentests need to treat connector packages and CDNs as threats until we can be sure they’re safe. Check out the full details here: (ledger.com).

Practical Tests

• Bill of Materials Reality Check: Take a good look at every wallet connector or provider package you're using, like web3modal/AppKit, connect kits, injected-provider helpers, and wagmi connectors. Don’t forget to include any “transitive” bits that bundlers might have added. Keep an eye out for any libraries loaded from a CDN at runtime, especially the ones that are lazy-loaded.
• Integrity Gates: It’s super important to check the Subresource Integrity (SRI) on all third-party scripts. You can either host them yourself or make sure to pin an exact version. Also, set up a tight Content-Security-Policy (CSP) that uses nonce/hash and strict-dynamic. Make sure to ban http/file sources and steer clear of any inline event handlers. You can find more info on this here.
• Update and Rollback Drills: To keep things safe, simulate a compromised CDN by serving up a mismatched SRI hash in staging. This is your chance to check if the site shuts down correctly and that your fallbacks and logging are picking it up--think SRI error telemetry and alerts. For more detail, check this out (developer.mozilla.org).

Emerging Best Practices

• Think of your connector UI libraries like you would with authentication widgets: make sure to pin, verify, monitor, and rotate your keys when there's a change in maintainers.
• Combine CSP nonces with SRI; it’s a good idea to test using Report-Only mode first so you don't accidentally disrupt production. Check out more about it here.

---

Attack path 2 -- Domain impersonation and deep‑link hijacking (WalletConnect, SIWE, mobile)

Two main types of real-world vectors are really causing problems:

a) Phishing pages that pretend to be your brand and deceive users into either scanning a WalletConnect QR code or clicking a “Connect” deep link.

b) Malicious Android apps that register for “wc:” and snag those links for themselves.

What to Verify in a Pentest

• WalletConnect Verify Alignment: Make sure your dapp’s metadata.url matches the exact domain that users see. Also, check that wallets integrating Verify register your site as VALID (not UNKNOWN/INVALID/THREAT). It's a good idea to try out some domain mismatches, like www versus apex or different environments, to see if the wallet throws up any warnings. You can find more details here.
• SIWE Domain Binding: If you’re working with Sign-In with Ethereum flows, double-check that the signed message's domain, URI, chainId, and nonce all line up with the actual origin. This should be enforced on the server side too. Wallets should be set up to reject any SIWE “domain” that doesn’t match the request origin. Remember, your relying party needs to bind sessions to the address and enforce nonce and expiry. Check out the specifics here.
• Mobile Deep Links: When it comes to Android/iOS, you’ll want to test for deep-link hijacking and any wrong redirects. For instance, scan a QR code on phone A and ensure that the app opens or redirects only to the intended wallet. Also, make sure that wallets ignore incomplete “wc:” URIs that are only used for UX redirects. Don’t forget to validate Android App Links autoVerify to keep hostile apps from claiming your link space, and check how your wallet picker behaves when multiple apps register for wc:. More info is available here.
• Malicious Apps: It’s super important to make sure your user communications strongly discourage installing “WalletConnect” apps. Lately, there have been fake apps on Google Play (like “WallConnect”) that tricked users into losing their funds by impersonating the protocol. You can read more about this here.

Key Spec Details for Test Data

• The WalletConnect v2 pairing URI has a symmetric key (symKey) and lists the methods you can use. It's super important to make sure that any QR tampering or relay changes are picked up. Plus, don’t forget that expired pairing URIs should time out after five minutes. Check out more details here.

---

Attack path 3 -- Over‑privileged sessions and dangerous JSON‑RPC methods

Wallet connectors are all about negotiating capabilities. If your session proposal is too wide-ranging, a compromised frontend could jump in and make risky requests right away.

What to Look For

• Namespaces Hygiene: Take a close look at the requiredNamespaces and optionalNamespaces in the session proposal. It's a good idea to keep chains, methods, and events to a minimum. Make sure that wallets reject any invalid CAIP‑2 chain IDs and blank lists. As a tester, don't hesitate to get a little wild with namespaces - throw in some bad CAIP‑2 values, extra methods, or wrong prefixes, and see if the wallet kicks back the right error codes. Check out the details over at specs.walletconnect.com.
• Block Dangerous Methods: Make sure that dapps aren't requesting any deprecated or risky methods, like eth_sign. Just so you know, MetaMask has ditched eth_sign; if it's absolutely necessary, it should only be available through an advanced toggle. Your connector should lean towards signTypedData_v4 or personal_sign by default. You can read more about this in the MetaMask docs.

Example: a simple session for mainnet reads + SIWE

{
  "requiredNamespaces": {
    "eip155": {
      "methods": ["eth_call", "eth_signTypedData_v4", "personal_sign"],
      "chains": ["eip155:1"],
      "events": ["chainChanged", "accountsChanged"]
    }
  }
}

Fail case to catch in code review

When it comes to code reviews, there are a few common fail cases that can slip through the cracks. Here’s a rundown of what to look out for to keep things running smoothly:

1. Lack of Testing

One of the biggest red flags is when new code doesn’t come with proper tests. Ensure that there are sufficient unit tests, integration tests, or any other relevant testing methods. If you see code that’s not tested, it's a good idea to ask:

• Is there a reason tests were skipped?
• How do we know this code works as intended?

2. Hardcoded Values

Hardcoding values can create all sorts of headaches down the line. Look for instances where developers have fixed values sprinkled throughout the code instead of using constants or configuration files.

• Check for magic numbers or strings.
• Suggest using environment variables or configuration management.

3. Poor Error Handling

Robust error handling is crucial. If the code doesn’t account for potential failures, it could lead to frustrating user experiences. During your review, ask yourself:

• Are errors logged?
• Is there a fallback mechanism in place?

4. Unoptimized Code

Efficiency matters! Review the code for any noticeable performance issues. Look out for:

• Nested loops that could be simplified.
• Any unnecessary computations that could be avoided.

5. Inconsistent Naming Conventions

Clear naming helps everyone understand the code better. If you notice inconsistent naming, it could confuse future developers. Keep an eye out for:

• Variables or functions that don’t follow the agreed conventions.
• Names that don’t clearly convey their purpose.

6. Ignoring Code Style Guidelines

Consistency in style makes code more readable. If the code strays from the established style guidelines, it can make things messy. Check for things like:

• Indentation issues.
• Inconsistent use of brackets or whitespace.

Conclusion

Next time you're diving into a code review, keep an eye out for these common pitfalls. Catching these fail cases can save the team a lot of time and headaches down the road!

{
  "requiredNamespaces": {
    "eip155": {
      "methods": ["eth_sendTransaction","eth_sign","eth_signTransaction","wallet_addEthereumChain"],
      "chains": ["eip155:1","eip155:10","eip155:42161","eip155:43114"],
      "events": ["*"]
    }
  }
}

Standards to Anchor Your Checks

• Keep an eye on the EIP‑1193 provider behavior, including events and requests, as well as error codes. It's super important that wallets rate-limit and validate all incoming data. You can check out more details here.

---

Attack path 4 -- Signature phishing (Permit/EIP‑712/Permit2) and “blind approval” drains

Drainers often find a way around on-chain approve prompts by using off-chain EIP-712 signatures (like Permit/EIP-2612 or Uniswap Permit2) to get transfer rights, which makes it super easy for them to drain multiple assets quickly. A lot of losses in 2024-2025 can be traced back to just one Permit2 signature. It’s a good idea for pentesters to replicate these signatures and check the user experience of your wallet, along with your security extensions and backend detections. (fullycrypto.com)

Pentest Steps to Uncover Real Risks

• Start by pushing those Permit2 prompts with big allowances and extended deadlines. It’s crucial to double-check that wallets provide clear, human-readable summaries. Make sure they raise flags for “unlimited approval” and display deadlines in local time. And hey, don’t let your UI ever default to MAX_UINT. You can find more about it here.
• Next up, let’s talk about SIWE versus non-SIWE. It’s super important to ensure that your logins don’t rely on EIP-712 domains that are used for approvals. Take a moment to verify that your domain separator has everything it needs: the name, version, chainId, and verifyingContract. For more details, check this link: EIP 712.
• Finally, don’t overlook contract-wallet signing. Make sure you’re validating the ERC-1271 paths for smart accounts. Also, confirm that your backend treats signature verification based on the chain. This is a critical step! For more info, you can read about it here.

Incident patterns to cite in risk briefings

• We’ve seen a concerning trend with single-signature Permit2 drains, with over $1.3 million taken from PEPE holders in 2024. Multiple public analyses highlight how social engineering plays a huge role in this. Check out more details here.
• There’s also been a noticeable spike in phishing incidents in 2024, particularly around airdrops and compromised social media accounts. The drainer kits seem to be switching brands, moving from Inferno to Angel. You can read more about this here.

Mitigations to Validate

• Wallet-side: It's a good idea to use eth_signTypedData_v4 or personal_sign. Make sure to clearly show “who/what/to whom/amount/deadline” on the screen, and definitely alert users if there are any “unlimited” approvals.
• Dapp-side: Try to cap allowances based on exact needs, set short expiry times, and display token icons and decimals. Don't forget to call revoke helpers after the flow is complete, and support EIP-5267 to highlight domain parameters for clients. Check it out here: (eips.ethereum.org).

---

Attack path 5 -- Chain switching/addition and RPC tampering

When a dapp prompts wallets to add or switch networks (thanks to EIP‑3085 / EIP‑3326), it’s pretty simple for bad actors to steer users toward a harmful RPC that can mess with balance reports and approval routes. So, it's important that your connector handles these network requests just like it would with authentication prompts.

What to Test and Enforce

• First off, make sure you're asking for explicit confirmation when it comes to wallet_switchEthereumChain and wallet_addEthereumChain. This means showing the requester’s origin and the chain metadata. It's super important that wallets check the chainId against the eth_chainId from the given RPC URL, and don’t let anything that isn't HTTPS or file schemes slip through. For more details, check out the EIP documentation.
• Next, validate those chain IDs with the official registries--specifically, the ethereum-lists/chains.json. And remember, never allow duplicate chain IDs in the wallet. You can find more on this at GitHub.
• Lastly, don’t forget about replay safety! Make sure that when you’re signing, it’s linked to the chainId, not just the values reported by the RPC. All the EIPs--EIP-155, EIP-695, and EIP-1344--should match up properly. You can read more about it in the EIP documentation.

---

Attack path 6 -- ERC‑4337 smart‑account flows through connectors (bundlers/paymasters)

Connectors are starting to show off account-abstraction routes like eth_sendUserOperation. However, when dapps are not set up correctly, it can really open the door for bad actors. They can take advantage by swapping out callData or altering paymaster terms, or even by sending User Operations (UOs) to sketchy bundlers or paymasters, which can lead to drained assets.

Pentest Actions

• First off, make sure your connector is only chatting with those allow-listed bundlers and paymasters. To test this, go ahead and set up a “rogue bundler” endpoint. You should confirm that your app or wallet either refuses to connect or at least shows a clear warning about the risks involved. Check out the details here.
• Next up, let’s throw some sponsorship requests at your wallet with some outrageous gas fee fields and unexpected paymaster post-operations. Take note of whether the wallet’s simulator catches any hidden value transfers. You can dive deeper into this here.
• If you're using WalletConnect’s Blockchain API for bundlers (like Pimlico), make sure to validate the projectId scoping for each chain. This is crucial to prevent any cross-project reuse. More info on that can be found here.

Evolving context: The 4337 JSON-RPC has now been wrapped up into ERC-7769. Make sure your infrastructure is up to speed with the finalized method shapes and that your simulations and alerts can handle those newer features, like the 7702 authorizations where they're enabled. Check it out here: (eips.ethereum.org)

---

Attack path 7 -- Multi‑injected providers and extension spoofing

In the world of browsers, a bunch of extensions are competing to tap into window.ethereum. Enter EIP‑6963, which smooths out the whole discovery process. It does this through event-based multi-provider announcements, helping to cut down on spoofing and overriding risks. Plus, it makes it way easier to choose the right wallet with its improved selection modals.

Pentest Checks

• Make sure your dapp is set up with EIP‑6963 discovery (or a modern library that supports it) and doesn't just go with the flow of whichever extension happens to be the "winner." Try out different installed wallets to ensure that the right one is picked every single time. You can check out more about it here.
• Keep an eye on branding issues: logos, IDs, and origins should come directly from the provider info, rather than relying on some guesswork. For more details, head over to this link.

---

Field‑tested pentest checklist (use this as your runbook)

Minimum‑Viable Tests That Catch >80% of Connector Failures in the Wild:

When it comes to ensuring that our connectors are running smoothly, it's crucial to implement some basic tests that can flag a high percentage of potential issues. Here’s a quick rundown of the minimum-viable tests that can help us catch over 80% of connector failures that might pop up in real-world scenarios:

1. Functionality Tests

Make sure that the basic functionalities of the connector are working as expected. This means testing data input and output, and verifying that everything aligns with the specifications.

2. Performance Tests

Check how the connector performs under different loads. It’s important to know how it behaves under stress, so running tests that simulate peak usage can reveal potential bottlenecks.

3. Error Handling Tests

Test how the connector responds to various error scenarios. It's essential to ensure it handles these gracefully, providing useful error messages rather than just crashing or failing silently.

4. Integration Tests

Run tests to verify that the connector plays nicely with other components in the system. Incompatibilities can lead to failures, so integration testing is key.

5. Boundary Condition Tests

Don’t forget to test the extremes. Inputs at the upper and lower limits can reveal hidden issues, so it’s worth it to push the boundaries and see how the connector holds up.

By implementing these minimum-viable tests, you’ll be able to catch a significant portion of connector failures before they become a headache out in the wild!

1. Verify/Origin Binding

• WalletConnect Verify: Works great on production and staging environments; but if you want to test, just force it to INVALID or THREAT to check out those wallet warnings.
• SIWE: Make sure to reject connections when the domain, uri, or chainId don’t line up with the origin. It's also important to enforce nonce and expiry, and tie sessions to the wallet address. Check out the details in the WalletConnect docs.

2) Session Capability Minimization

• Namespaces: When you're making requests, always aim for the least-privilege methods and events for each chain. Double-check that the wallet turns down any CAIP‑2 errors and doesn't allow extra methods.
• Signing Methods: Steer clear of deprecated or opaque signing options like eth_sign. Instead, go for signTypedData_v4 or personal_sign. You can get more details over at specs.walletconnect.com.

3) Signature‑phishing defenses

• Check out EIP‑712/Permit2 situations where unlimited allowances and lengthy deadlines come into play. Make sure to validate wallet UI warnings and set your app's allowance limits.
• Don't forget to test your revocation flows and keep an eye out for any off‑chain Permit grants on the server side. (fullycrypto.com)

4) Network Prompts and RPC Integrity

• The functions wallet_addEthereumChain and wallet_switchEthereumChain need clear user approval. They should also display the chain's origin and have RPCs pinned. Make sure to validate the chainId using eth_chainId and public registries, and don’t accept any non-HTTPS connections. (eips.ethereum.org)

1. 4337 pathways

• Let’s allow-list those bundlers and paymasters, run some simulations on malicious postOps, and make sure that signing previews clearly show the net asset impact before giving the green light. (eips.ethereum.org)

1. Deep Linking and Mobile

• Check out Android App Links with autoVerify. It's super important to make sure that no QR-scans accidentally send users to the “wrong” apps. Make sure to test out several wallet apps on the same device. Also, don’t forget to reject any incomplete wc: URIs when it comes to signing. (developer.android.com)

7) Supply-Chain Guardrails

• Use SRI and CSP with strict-dynamic settings on connector libraries. Implement fail-closed drills to handle CDN mismatches. And remember, steer clear of loading connect kits from mutable CDNs in production. Check out more about it here.

1. Run-time threat simulation

• Turn on wallet-side security alerts by using transaction simulation tools (like Blockaid in MetaMask). Make sure to check out the alerts across your main networks and track those pesky false positives. (metamask.io)

---

Concrete examples (pass/fail with fixes)

WalletConnect Verify Failing on Staging

• Symptom: Your wallet’s displaying UNKNOWN/INVALID for app.staging.example.com, even though you've set metadata.url to https://example.com.
• Root cause: There’s a mismatch with the metadata.url, plus your staging environment isn’t included in your project’s domain config.
• Fix: Make sure to align app.metadata.url with the exact origin and add the staging domain to the allowlist. After that, just rerun it, and you should see the wallet showing VALID, plus those pesky phishing banners will be gone. For more details, check out this link: (walletconnect.com).

Over-privileged namespaces

• Symptom: Your connect modal asks for eth_sendTransaction right when you connect, even on a read-only page.
• Risk: If your frontend gets compromised, it could quickly start sending out transaction requests without you knowing.
• Fix: Separate “connect-only” sessions from “transact” ones. Upgrade the scopes on the fly when the user actually wants to make a transaction. Check out the details here.

Permit2 Drain Exposure

• Symptom: Users have the ability to approve an endless amount of token spending with just one EIP‑712 signature. Plus, there’s no deadline or user interface summary to give them a heads up.
• Fix: We need to put a cap on allowances, enforce shorter deadlines, and provide clear, human-readable previews for typed data. Also, it’s essential to raise a warning for unlimited approvals. Let's make sure to cross-check with wallet alerts and create a user-friendly experience for revocation. (fullycrypto.com)

Chain Switching to Unverified RPC

• Symptom: When a Dapp suggests a new chain that uses a third-party RPC, the wallet doesn’t check if the chainId is consistent.
• Fix: The wallet should grab the eth_chainId from the proposed RPC and check it against the requested chainId. If they don’t match, it should reject the connection. Dapps should stick to well-known chain registries. (eips.ethereum.org)

---

2025‑ready control set you can standardize

Adopt these as acceptance criteria for every release that involves “Connect Wallet”:

• Domain binding by default
  • WalletConnect Verify is built in, and SIWE makes sure to strictly enforce domain/URI/nonce/expiry; sessions are tied to the address. (docs.walletconnect.network)
• Capability-minimized sessions
  • We’ve got separate read and write sessions; avoid asking for eth_sign; make sure to log and alert on any unexpected method requests. (docs.metamask.io)
• Human-readable signing and simulation
  • Always display the chain, contract, token, amount, and deadline; enable wallet-side simulation and alerts across supported chains (like MetaMask and Blockaid). (support.metamask.io)
• Network prompt hardening
  • Users need to give explicit confirmation when adding or switching; ensure to validate chainId through eth_chainId and reliable public registries; pin RPCs and avoid using http/file schemes. (eips.ethereum.org)
• SRI + strict CSP on connector code
  • It’s a good idea to self-host critical JavaScript; pin versions and keep an eye out for SRI failures; have fallbacks in place and use report-only CSP for safe iterations. (developer.mozilla.org)
• Mobile linking safety
  • With Android App Links, make use of autoVerify; don’t accept incomplete wc: URIs; test out multiple wallets on a single device; document official wallet apps and be cautious of any “WalletConnect” impersonators. (developer.android.com)
• 4337 hygiene
  • Stick to trusted bundlers and paymasters; make sure EIP-712 userOp hashes are visible in previews; audit postOps flows; and stay updated with ERC-7769 RPC shapes. (eips.ethereum.org)
• Multi-wallet discovery
  • Go ahead and implement EIP-6963; never assume that window.ethereum is “the” wallet. (eips.ethereum.org)

---

Brief in‑depth: how to fuzz WalletConnect sessions like an attacker

Use a Gray-Box Approach Against Your DApp in Staging with a Controlled Wallet:

Using a gray-box approach can be super helpful when testing your decentralized application (dApp). Here's how you can do it effectively:

1. Set Up a Controlled Wallet: First things first, create a controlled wallet for your testing. This ensures that you can manage how the wallet interacts with your dApp without risking any real assets.
2. Deploy Your DApp in Staging: Make sure your dApp is deployed in a staging environment. This is key for testing, as it allows you to simulate real-world usage without the pressure of a live environment.
3. Conduct Gray-Box Testing: With your controlled wallet ready and your dApp in staging, you can start performing gray-box tests. This means you’ll have partial knowledge of the internal workings of your dApp while still trying to discover how it behaves under various scenarios.
4. Test Scenarios:
   • Functionality Tests: Check that all features work as intended.
   • Security Tests: Look for vulnerabilities, like reentrancy attacks or overflow issues.
   • Performance Tests: See how your dApp performs under load.
5. Analyze Results: After testing, take some time to go over the results. Identify any weaknesses or areas for improvement. This critical step can help you beef up your dApp's security and reliability before launching it out into the wild.
6. Iterate: Don’t be afraid to go back and tweak things based on your findings. The goal here is to refine your dApp until it’s rock-solid.

By following these steps, you not only gain valuable insights into the performance of your dApp but also ensure a more secure and reliable product in the long run. Remember, thorough testing can save you from a lot of headaches down the line!

1) Namespace Fuzzing

• Try sending proposals that include: empty chains, non-CAIP-2 IDs, banned methods like eth_sign, and excessive chains. Be on the lookout for rejections with specific codes, like 5100 or 5001. And don’t forget to check that your client stops connecting if there’s a mismatch. You can find more details over at specs.walletconnect.com.

1. Pairing URI tampering

• Tweak the symKey, relay-protocol, and expiryTimestamp in the wc: URI. The wallet should reject this and make sure the pairing expires in about 5 minutes if there’s no activity. If the pairing's active, it should extend the expiry every time it’s used. (specs.walletconnect.com)

1. Check those negative tests

• Set up a look-alike domain and make sure the wallets flag it as THREAT/INVALID. Remember to block it or give a hard warning. You can find more info here: docs.walletconnect.network

1. 4337 endpoints

• Direct the connector to a bundler that’s not on the allow-list; make sure it fails before signing. (eips.ethereum.org)

---

Executive wrap‑up

The connector layer is really where a lot of the modern web3 risk hangs out. The best fixes for these issues aren't anything too wild; they're pretty straightforward. Think about things like:

• binding origins
• using least-privilege sessions
• implementing human-readable and typed signatures
• having simulation-backed warnings
• ensuring you're on verified networks and RPCs
• setting up hardened frontends with SRI and CSP to guard against supply-chain tricks

By putting into practice some tools like WalletConnect Verify, doing SIWE domain checks, exploring EIP-6963 discovery, and adopting ERC-7769-aware 4337 flows, plus adding MetaMask-style security alerts, you can really cut down on risks from phishing and wallet drainers that specifically target those connections. Check out more details here: (docs.walletconnect.network).

---

References called out in this guide (selected)

• Check out the Reown/WalletConnect Verify API and the fresh rebrand updates coming in 2025. (reown.com)
• Don’t miss the details on the Ledger Connect Kit incident and how they handled the situation back in December 2023. (ledger.com)
• Dive into the ScamSniffer phishing and drainer telemetry from 2024. (drops.scamsniffer.io)
• Take a look at the MetaMask deprecations and get some safe signing tips. (docs.metamask.io)
• Explore session namespaces, pairing URIs, and the lifecycle in WalletConnect v2. (specs.walletconnect.com)
• Learn about SIWE (EIP‑4361) for domain binding. (eips.ethereum.org)
• Get the scoop on EIP‑3085/3326 and the security considerations around chain add/switch; plus, check out chain registries. (eips.ethereum.org)
• Find out about the ERC‑7769 / ERC‑4337 JSON‑RPC (eth_sendUserOperation) updates. (eips.ethereum.org)
• Check out EIP‑6963 for multi‑wallet discovery. (eips.ethereum.org)
• Finally, see how to implement SRI and CSP strict‑dynamic. (developer.mozilla.org)

Description

This is your go-to, hands-on playbook for penetration testing wallet connectors in web3 apps. It’s all about the real attack paths that popped up in 2024-2025, along with solid controls to shut them down. Inside, you’ll find test cases for things like Verify/SIWE domain binding, minimizing namespaces, blocking Permit2 drains, tackling chain add/switch abuse, navigating 4337 flows, managing deep links, and beefing up supply-chain security.