ryanmcdonough wanted database-level access controls on everything, not just profiles

A proposed security tightening that would have pushed authorisation down into the database for every content table - closed before it landed.

securitymulti-tenant

Most legal apps enforce 'who can see what' in application code. ryanmcdonough's pull request proposed moving that enforcement down a layer, into the database itself, using row-level security - a feature that lets the database refuse to return rows the requesting user isn't entitled to, regardless of what the surrounding code does.

The fork already had this protection on user profile data. The proposal was to extend it across every other content table, so any future read or write path inherits the same access policy by default. It's the kind of change that quietly closes a category of bug: a developer forgetting an access check in new code can't accidentally leak data, because the database itself won't hand it over. The PR was closed on 8 May without merging and without an explanation from the author.

So what Worth watching for anyone building multi-tenant legal tools - this is the pattern that prevents the 'we forgot to filter by client_id' class of breach, and it's notable that it was tried and pulled back.

View this fork on GitHub →

Spotted something wrong? Or know the PR text has fresher detail than the writeup above?