fix(base-account): parse the SIWE nonce correctly and bind verification to the app domain

[Dusk1e]

Correction (2026-08-11): an earlier version of this description said issue #1502 had no PR. That was wrong — five PRs already target this file. I missed them because I listed open PRs with a limit that truncated before reaching May. The section at the bottom now sets out how this PR relates to them, and I'm happy to close this in favour of one of them.

The Authenticate users guide ships an Express example that rejects every valid login, and a verification step that accepts signatures a user produced on someone else's site. Both are in code a developer is meant to copy into a production auth endpoint.

1. The nonce is never extracted, so /auth/verify always returns 400

docs/base-account/guides/authenticate-users.mdx:207 reads the nonce with:

const nonce = message.match(/at (\w{32})$/)?.[1];

In an EIP-4361 message the nonce is on its own Nonce: <value> line and Issued At: comes after it, so nothing sits at the end of the string for $ to anchor to. The match is always null, the guard below it fires, and the endpoint answers 400 Invalid or reused nonce for a completely valid login.

Using the message format this repo documents at docs/base-account/reference/core/capabilities/signInWithEthereum.mdx:128:

const message =
  "localhost:3000 wants you to sign in with your Ethereum account:\n" +
  "0x1234567890123456789012345678901234567890\n\n" +
  "Sign in with Ethereum to the app.\n\n" +
  "URI: http://localhost:3000\nVersion: 1\nChain ID: 8453\n" +
  "Nonce: abc123def456\nIssued At: 2024-01-15T10:30:00Z";

message.match(/at (\w{32})$/)?.[1];   // undefined  <- the guide
message.match(/Nonce: (\w+)/)?.[1];   // 'abc123def456'

Two other pages in this repo already read the nonce correctly — signInWithEthereum.mdx:216 and framework-integrations/privy/authentication.mdx:227 — so this guide was the only one reading it incorrectly. This PR uses viem's parseSiweMessage rather than another regex.

2. Verification is not bound to your domain

Both snippets verified with:

const valid = await client.verifyMessage({ address, message, signature });

verifyMessage only answers "does this signature match this message". It never looks at the domain field, so a SIWE signature a user was asked to produce on evil.com verifies against your endpoint as well. EIP-4361 requires the relying party to check domain against its own host (issue #1502).

Swapped to verifySiweMessage, which validates domain, nonce and expiry before checking the signature. It still routes through verifyHash internally, so ERC-6492 and ERC-1271 signatures from not-yet-deployed Base Accounts keep verifying exactly as before — the guide's own note at line 62 stays accurate.

Verification

I ran the proposed server code unmodified against a local node, signing real messages with viem:

Case	Before	After
Legitimate login	400 Invalid or reused nonce	200 { ok: true }
Replay of the same signature	400	400 Invalid or reused nonce
Signature minted for evil.com	200 { ok: true }	401 Invalid signature
Nonce the server never issued	400	400 Invalid or reused nonce

Row 1 is the functional bug, row 3 is the security one. Rows 2 and 4 confirm the existing replay protection still behaves.

Relationship to the existing PRs on this file

Five PRs already touch this guide, all opened in May and all still unreviewed. For whoever triages this, here is what each actually changes, checked against viem 2.55.13:

PR	Fixes the nonce regex	Adds domain binding	Note
#1503	no	yes	Destructures const { isValid } = await verifySiweMessage(...). That function returns a boolean, so isValid is undefined and the endpoint would answer 401 for every login.
#1542	yes	yes	Closest to this PR. Moves nonces.delete(nonce) to after verification, so a nonce survives a failed attempt and two concurrent requests can both pass the has() check.
#1553	no	yes	Manual parseSiweMessage(...).domain comparison; keeps verifyMessage.
#1559	no	yes	Passes nonce to verifySiweMessage, but that nonce still comes from the broken regex.
#1560	no	no	Separate issue (Math.random() nonces), no overlap.

#1542 covers the same two defects this PR does and is the older submission. The differences here are that the nonce stays an atomic check-and-consume (nonces.delete as the guard, as in the current guide), the domain constant does not default to localhost:3000, and the behaviour is backed by the run above. If you would rather take #1542, this can be closed — the important thing is that one of them lands, because the guide is currently broken for every reader who copies it.

Notes

• node scripts/lint-mdx.js docs/base-account/guides/authenticate-users.mdx reports the same 9 errors and 1 warning before and after this change — no new findings introduced.
• This deliberately does not touch the client-side nonce generation discussed in security: replace Math.random() with crypto.randomUUID() for SIWE nonces #1560, fix(docs): warn that client-side SIWE nonce provides no replay protection #1761 and fix(docs): warn that client-side SIWE nonce provides no replay protection #1722.

[cb-heimdall]

🟡 Heimdall Review Status

Requirement	Status	More Info
Reviews	🟡 0/1	Denominator calculation Show calculation 1 if user is bot 0 1 if user is external 0 2 if repo is sensitive 0 From .codeflow.yml 1 Additional review requirements Show calculation Max 0 0 From CODEOWNERS 0 Global minimum 0 Max 1 1 1 if commit is unverified 0 Sum 1

[Lrifton92]

Checked against EIP-4361 and the viem source: the old /at (\w{32})$/ can never match (the SIWE message ends with Issued At: / optional fields, never the nonce), and parseSiweMessage uses Nonce: (?<nonce>[a-zA-Z0-9]+). verifySiweMessage returns a boolean, enforces domain (message.domain !== domain -> false), checks expirationTime/notBefore, and still goes through verifyHash so ERC-6492 signatures keep working. viem/siwe export path is valid. The fix is correct and complete for what it claims — LGTM.

One follow-up worth a look, not blocking: the frontend snippet earlier in this guide still defaults to a client-generated nonce (window.crypto.randomUUID()) with the /auth/nonce fetch commented out. Now that the Express server correctly rejects nonces it did not issue, copying both snippets as-is yields 400 Invalid or reused nonce on every login. Making the fetch the default (or noting that the Express example requires server-issued nonces) would close that gap.

[Lrifton92]

Pre-existing, optional: parseSiweMessage(message) throws if message is missing or not a string, which an Express 4 async handler won't catch (hanging request / unhandled rejection). A typeof message !== 'string' guard returning 400 would make the example safer to copy-paste.

[Lrifton92]

Nit: worth stating this must equal the message's domain field exactly, i.e. host including port (localhost:3000 in dev), otherwise readers get a puzzling 401 locally.

[cb-heimdall]

Review Error for Lrifton92 @ 2026-08-15 22:26:16 UTC
User failed mfa authentication, either user does not exist or public email is not set on your github profile. \ see go/mfa-help

[Dusk1e]

Checked against EIP-4361 and the viem source: the old /at (\w{32})$/ can never match (the SIWE message ends with Issued At: / optional fields, never the nonce), and parseSiweMessage uses Nonce: (?<nonce>[a-zA-Z0-9]+). verifySiweMessage returns a boolean, enforces domain (message.domain !== domain -> false), checks expirationTime/notBefore, and still goes through verifyHash so ERC-6492 signatures keep working. viem/siwe export path is valid. The fix is correct and complete for what it claims — LGTM.

One follow-up worth a look, not blocking: the frontend snippet earlier in this guide still defaults to a client-generated nonce (window.crypto.randomUUID()) with the /auth/nonce fetch commented out. Now that the Express server correctly rejects nonces it did not issue, copying both snippets as-is yields 400 Invalid or reused nonce on every login. Making the fetch the default (or noting that the Express example requires server-issued nonces) would close that gap.

You're right but that part is already covered by #1761 and #1722, so I left it alone to avoid overlapping with them.