Security Review
Production-reachable bulk deletion of auth-table rows, protected only by a role check and a single-tap confirm.
clearDemoBoard performs await Users.removeAll((u, $) => $.ids.includes(u.id), { ids: demoUserIds }) against the table configured as the app’s auth table, plus cascading removeAll across posts, deals, comments, reactions, kudos, and badges. The scoping logic is correct as written and its two subtle type traps are handled explicitly. The severity comes from blast radius, not from a defect: correctness rests entirely on the demoSeed tag being present and truthy on exactly the right rows, there is no dry-run or preview, no server-side audit record of what was removed, and the only barrier in front of it is auth.requireRole('admin') plus one confirm sheet. Any admin — including one auto-granted the role by the bootstrap path in F8 — can trigger it. A partial failure is not transactional: engagement, posts/deals, and users are deleted in three separate awaited batches, so an error midway leaves the board half-torn-down.
RECOMMENDATION
Add a defence-in-depth guard that does not depend on the tag being right: refuse to run if the number of rows about to be deleted exceeds the known demo cast size (28 people), and refuse if any row in the delete set has a non-null email (a real, verified person always has one; a demo row never does). Require typed confirmation in the UI rather than a single tap, and log the deleted ids and counts via console.log so the action is reconstructible from method logs.
Does this mean for each finding I will have to ask REMY to fix. It introduced these issues so it costs to fix.
Sign in to reply
You're browsing read-only. Sign in to post, upvote, or react, and we'll email you a 6-digit code.