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!
22 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
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.
So this topic was just highlighted at Bubblecon by @wesleywsls , and the solution offered was to add an extra condition on privacy rules saying “and is not empty.”
Do we know if this still works for “Created By?”
For example, if you delete a User, how does it affect “This User is Current User” ?
You could argue that there will never be a “Current User is empty” because even anonymous accounts have a Current User, but what if someone isn’t visiting the site from a browser and is just querying the API directly?
Should we be adding a condition that says the below?
Do we think this is bulletproof and robust against deletions? Would love to hear your thoughts @georgecollier @nico.dicagno
“and Creator is not empty” to all datatypes where This User is Current User is set
In my situation, “Current user is empty” is possible because I have the setting “Do not set cookies on new visitors by default” turned on in my app.
1 Like
Yeah I just realized it won’t work with my signup flow either.
The solution is actually simpler, for any user type I added “and Creator is not empty”
That way if a User is deleted, all their attached info is still private.
The recommendation is not ‘current user is not empty’. The recommendation is to have ‘organization is not empty’ ( as per organisation example)
1 Like
Also just avoid using the Creator field on all data types if at all possible…
1 Like
I’ve heard this before, why is that? Don’t want to create a duplicate User field on literally every single Thing unless there’s a really good reason. I don’t have any “assignments” in my app, only users can see their own stuff.
Because when you want to create something from the backend called from the front-end, or change who owns something, you’ll run into a wall because your whole app uses Creator which you can’t override.
When I create stuff from backend workflows (which is almost always), it shows the current user (user who created it) in the Created by field. Is there a specific example you’re thinking of? Or do you mean literally creating stuff in the editor, and then the creator shows up as “App admin?”
Yeah my app doesn’t currently require this and I don’t see it ever requiring it, but this would make sense if it did.
Edit: I would add that if your privacy rule depends on “Created by” then you’re 100% safe in that the field can never be modified. The privacy rule can never accidentally/maliciously be bypassed. So it has an added security benefit (you could argue a marginal one but I always consider tail risk).
Actually, you may not need this rule for deleting a user, scratch that. If you have the following privacy rule:
This Thing’s Creator is Current User
And you delete that User, then try to search for this on an incogneto/private page, you still can’t find it because Bubble always “assigns” a current user. The current user is never empty. It may still be prudent in cases where you’re not interacting through a browser, but I’m not sure how to test that.