Careful using only Current User's X in privacy rules

I’ve been auditing a few apps recently and quite a few have a similar issue.

A common privacy rule is This Thing’s X is Current User’s X. For example, in a B2B app, that might mean This Note’s Organisation is Current User’s Organisation. For some reason, the Organisation field of the Note never got assigned.

This Note’s Organisation is empty (due to error/logic bug)
and
Current user’s Organisation is empty (as user is not logged in)
therefore
This Note’s Organisation = Current User’s Organisation (as both are empty)
= Data is visible to non-authenticated users

If This Note’s Organisation is not assigned for whatever reason, it is likely better to hide it from everyone rather than make it visible to everyone. As such, a more robust privacy rule might be This Note’s Organisation is Current User’s Organisation and This Note’s Organisation is not empty. Orphaned data should be private, not public (a better safe than sorry approach).

If your app is perfectly built, it’s unlikely This Note’s Organisation would ever be empty due to the app design. However, if there’s some Bubble issue that stops the workflow in the middle of assigning the Organisation, or you add a new feature and forget to the same, then you could unwittingly make data public. Not good!

17 Likes

This is a great tip/warning! It’s definitely one of those edgecases that fly under the radar and I can think of a few scenarios where it applies. Thanks for pointing it out

Bumping it up for more people to read :slight_smile:

1 Like

The other scenario this happens is when deleting data. If, for example, you delete an Organisation, and forget to delete some data related to that Organisation (let’s say, it’s Invoices), then the Organisation field on the Invoice would become empty.

This is probably the most common scenario that could make a breach like this occur.