Original Summary

Someone left a comment on a post I made a couple weeks ago, walking through why my tenant isolation being enforced entirely in application code (every query manually scoped by org membership) was a real risk, not just a theoretical one. His framing stuck with me: the failure mode is never the route you're looking at right now, it's the one someone adds in a hurry eight months from now, copying a pattern from whatever file happened to be open. What actually changed my mind wasn't the general warning, it was one specific idea. Instead of adding row-level security as more rules to remember, set it up so an unset tenant context returns zero rows by default. No context, no data. That turns "someone forgot to scope a query" from a silent leak into an obviously broken, empty page. You'd catch it in five minutes of testing instead of from a support ticket. There's a nasty trap hiding in that setup too, apparently. RLS isn't enforced against a superuser or the table owner, so if you test as an elevated database role, everything looks fine and proves nothing. You have to verify as the actual runtime role the app connects with. I hadn't touched database-level isolation before this, always assumed careful code was enough. Curious whether other people building multi-tenant stuff went default-deny at the database from day one, or only added it after something already looked wrong.   submitted by   /u/NatureAccording1655 [link]   [comments]

  • 情报分类：硬件与数码
  • 分类依据：内容涉及硬件、数码产品或通信卡
  • 信息来源：Reddit · SideProject
  • 发布时间：2026/9/22 21:59:42