I’ve trying to understand the implication of some of my pricacy rules.
At sign in, I run a check if the email already exists. This means the email addresses have to be visible to all users, including anonymous.
I simply return a count; however, some content I’ve read suggests that the entire user object is returned and the count is done at the front end.
Can anyone validate this?
In short, no you don’t want to leave your emails publicly visible. Best to lock them down!
Bubble already checks if the email exists btw but anyway in general there’s a much safer way to do this kind of thing
If you want to return the count (or simply a yes or no to check if the email is available)
Create a backend workflow and do the search there. Make sure to use return data from api.
Then use this in your sign up workflow.
Thanks!
For this particular use case, I’m not overly concerned, as the user has to enter a valid email for it to be returned, but worth considering alternatives.
False. You can make it find in search without being visible to all.
False too if you use :count. You can always inspect what is returned by Bubble in the browser network tab..
I’m not a fan of this way to check if the email already exist. I prefer to just let Bubble check the credentials. This is also more secure.
Thanks @Jici - that’s some really helpful feedback!
I should clarify, the suggestion is that all visible fields for that user type are returned, not the whole object
Using the network tab as others have suggested is a quick way to check what data is being returned. I have a guide on this here (a bit old, but should still point you in the right direction).
A simple count will only return the needed data; the count. So the count is performed on the server, not the client. Here’s a quick example where I’m searching for users by email address:
I’m not a fan of this way to check if the email already exist. I prefer to just let Bubble check the credentials. This is also more secure.
I agree with this sentiment. It’s not that it’ impossible to verify an email address securely that way, but opening up privacy rules etc. increase the chance that you somehow by mistake reveal something that you didn’t intend. It broadens the attack surface, so to speak, and forces you as a developer to keep track of one more thing.
Keep in mind that just confirming that an email address exists in the database (without getting any other data) is in itself a potential breach of privacy. So even a “count: 1” visible in the network tab reveals something.
It’s hard to say what best and worst practice in a lot of scenarios, since these are all design decisions that are ultimately up to you as the developer to decide in a given scenario. But from a security perspective, it makes sense to make your app’s attack surface as small as possible, and strict privacy rules and letting Bubble handle authentication is a good way to protect yourself from unknowingly opening up vulnerabilities.
Thank you everyone for the in-depth feedback on this one.
That’s a really good point about revealing whether an email exists or not is a potential breach of privacy - my initial thought was “well, the user knows the email address, so I’m not giving that away”, but if a bad actor simply wanted to know if another user was registered to my site (for whatever reason), they could enter that user’s email, and voila, there’s their proof!
Annoyingly, I used a base template for these basic things, and the “this email already exists” function was already baked in, which I’ll now work to remove.
It’s great not only getting an answer to the specific question I asked, but also getting answers to the real question: “am I breaking privacy rules?”
Interesting discussion guys.
Well, in this case, for security reasons, how would you handle a flow where:
In this case, I need this verification at the initial step and I have these other things happening, like using the external service.
Do you think using a count in this scenario is dangerous, could it be avoided somehow?
How could I use only Bubble verification in this scenario, any suggestions for a case like this?
Should I make an API call to my own app, to a flow that returns a boolean and use that instead of count?
Any example apps with a similar flow?
My two cents on this one, because I’ve literally just worked on updating a similar process.
I have a few steps in my signup process:
Based on the feedback earlier, attempting to sign up with an existing email compared to a new email should be no different, so it’s now exactly the same on my site, but if the user already exists, they won’t get a verification email (they’re already verified).
What you could do where a user is trying to re-register with an existing email is, instead of sending the verification email (still say that you are in the front end), now send an email saying “a user has tried to sign up using this email, if you need to reset your password, do XYZ”
My limited understanding of privacy limits us to protecting what we have control of, but we can assume that a user has appropriate control of their email and access to it. Therefore sending a “here’s your verification link” to a new user and “do you need to reset your password” to an existing user, is not a breach of privacy.
One of the sign up or create account actions has a checkbox of ‘return user if already exists’ so that in a flow you will have either the newly created account or previously registered user account to use as a ‘result of previous step’ value, being the user, for use in subsequent steps.
Not sure if that works for your use case.
