harden: a page can open unbounded concurrent approval windows #405

New Issue

2026-09-21T20:37:56+02:00

clawbot commented

2026-09-21 20:37:56 +02:00

Severity: hardening.

Where. src/background/index.js:462-483 (requestApproval), 520-535
(requestSignApproval) and 395-458 (openApprovalWindow). Only transaction
approvals hold a single slot (txApprovalSlot).

What is wrong. Site-connection and message/typed-data signing approvals are
not coalesced or capped, so each eth_requestAccounts or personal_sign call
opens a new approval window; a page can open many at once.

Why it matters. A wall of identical prompts is harassment / denial of
service, and pushes the user toward a reflexive approve.

Reproduction. An unconnected page calls eth_requestAccounts in a loop; each
call opens another approval window. A connected page does the same with
personal_sign.

Acceptable. Coalesce pending requests per origin and method (return the same
pending promise), cap the number of open approval windows, and refuse further
requests with EIP-1193 -32002 while one is pending.

Definition of done.

Repeated same-origin, same-method approval requests do not open more than
one window.
A further request while one is pending is refused with -32002.
A test asserts a loop of requests yields at most one open approval and one
-32002 per extra call.

Model: fable-5-1 (review); opus-4-8 (filing)

Severity: hardening. **Where.** `src/background/index.js:462-483` (`requestApproval`), `520-535` (`requestSignApproval`) and `395-458` (`openApprovalWindow`). Only transaction approvals hold a single slot (`txApprovalSlot`). **What is wrong.** Site-connection and message/typed-data signing approvals are not coalesced or capped, so each `eth_requestAccounts` or `personal_sign` call opens a new approval window; a page can open many at once. **Why it matters.** A wall of identical prompts is harassment / denial of service, and pushes the user toward a reflexive approve. **Reproduction.** An unconnected page calls `eth_requestAccounts` in a loop; each call opens another approval window. A connected page does the same with `personal_sign`. **Acceptable.** Coalesce pending requests per origin and method (return the same pending promise), cap the number of open approval windows, and refuse further requests with EIP-1193 `-32002` while one is pending. **Definition of done.** - [ ] Repeated same-origin, same-method approval requests do not open more than one window. - [ ] A further request while one is pending is refused with `-32002`. - [ ] A test asserts a loop of requests yields at most one open approval and one `-32002` per extra call. Model: fable-5-1 (review); opus-4-8 (filing)

clawbot referenced this issue

2026-09-21 20:39:01 +02:00

security: pre-1.0 review of key handling, DEBUG mode and RPC/dApp input validation #383

~~clawbot referenced this issue 2026-10-03 14:21:22 +02:00~~

Review toward 1.0: identify and file all next steps #382

clawbot commented

2026-10-04 17:26:29 +02:00

Plan. One PR on a branch cut from next, base next.

Site-connection (eth_requestAccounts) and message / typed-data signing approvals get the same single-slot treatment transaction approvals already have (txApprovalSlot): while one approval of a kind is open for an origin, a further request of that kind from that origin is refused with EIP-1193 -32002, without opening a window. Same wording and code the transaction path already uses for -32002.
Reuse the existing slot mechanism rather than a second one; if the three kinds can share one small helper, do that.
Tests: a loop of eth_requestAccounts from one origin, and a loop of personal_sign from a connected origin, each open at most one approval window and get one -32002 per extra call; a different origin is not blocked by the first.

Model: opus-5-5

Plan. One PR on a branch cut from `next`, base `next`. - Site-connection (`eth_requestAccounts`) and message / typed-data signing approvals get the same single-slot treatment transaction approvals already have (`txApprovalSlot`): while one approval of a kind is open for an origin, a further request of that kind from that origin is refused with EIP-1193 `-32002`, without opening a window. Same wording and code the transaction path already uses for `-32002`. - Reuse the existing slot mechanism rather than a second one; if the three kinds can share one small helper, do that. - Tests: a loop of `eth_requestAccounts` from one origin, and a loop of `personal_sign` from a connected origin, each open at most one approval window and get one `-32002` per extra call; a different origin is not blocked by the first. Model: opus-5-5

clawbot referenced this issue from a commit

2026-10-04 17:42:12 +02:00

harden: one connection and one signature prompt per site at a time (closes #405)

clawbot referenced a pull request that will close this issue

2026-10-04 17:42:35 +02:00

harden: one connection and one signature prompt per site at a time #433

clawbot commented

2026-10-04 17:42:40 +02:00

Built in #433: while a site has a connection or signature prompt unanswered, a further request of that kind from it gets -32002 and opens no window. All signing methods count as one kind; other sites are unaffected.

Model: opus-5-5

Built in https://git.eeqj.de/sneak/AutistMask/pulls/433: while a site has a connection or signature prompt unanswered, a further request of that kind from it gets `-32002` and opens no window. All signing methods count as one kind; other sites are unaffected. Model: opus-5-5

clawbot referenced this issue from a commit

2026-10-04 18:21:26 +02:00

harden: one connection and one signature prompt per site at a time (closes #405)

clawbot referenced this issue from a commit

2026-10-04 19:08:34 +02:00

harden: one connection and one signature prompt per site at a time (closes #405)

clawbot closed this issue

2026-10-04 19:43:11 +02:00

clawbot referenced this issue from a commit

2026-10-04 19:43:12 +02:00

harden: one connection and one signature prompt per site at a time (closes #405)

Sign in to join this conversation.