Best Method to Restrict Page Access?


Is there a better way to restrict page access than the method I’m currently using?

Right now, I have all the elements of the dashboard page in an entire group called “Group All” and it only shows when the current user is an admin. I also have the dashboard page redirected to the login when the user is not an admin.

Is there a better way to go about this? Right now, the redirect is slow, so the dashboard shows a blank page for a few seconds before redirecting to the login page. It would be nice to have an instant redirect, but how secure is this method?



Maybe a solution would be to display by default a text saying “You don’t have permissions for this page” - Hide this msg when user is admin.
So users can see that alert while they are redirecting

I suppose, but will using the redirect workflow we’re using leave our dashboard page exposed to potential hackers? Is there any other way we can restrict access without the redirect?

See here for prior discussion on this topic, and for more do some searching on the forum for “privacy” and “security” and you’ll find plenty of posts in addition to the privacy section in the Bubble manual.

Not sure if you read my post, but that’s exactly what I did. Just wanted to know if there’s anything better

1 Like

Hmm… I usually do redirect. You can also try to group everything on the page and disable load on page load, then a conditional that makes it visible to admins. Also, like @ed727’s suggestion, because I personally use Privacy Rules, Redirects and I make the system check every workflow ran on the admin page to make sure that the user is actually an admin

Yeah, sounds like everyone’s doing the same thing. I did notice though that Wappler has a restrict feature for pages. Guessing Bubble doesn’t have it, only for data


Please consider that Bubble is a visual programming language. You can approach the restricting of users to a page in different ways. :+1:t2:

It’s not secure because it’s client side. You should still do it, but in addition you’d need to do the server side stuff (privacy rules, conditions on data writing workflows, plus sometimes backend workflows, ensuring APIs are secure).


Thanks Ed! This is the answer I was looking for! We are storing social security numbers and passport IDs, so would that level of security be necessary?

Storing that kind of info takes things to a whole new level IMO since it is so sensitive. If I held that type of data I’d do a ton of research/reading on privacy and build in as many protections as possible. I’d also have to make a basic decision on whether Bubble can provide the level of security I need from both a security and a legal perspective (I don’t know the answer to this question in your case).

In addition to the “basics” of privacy rules and workflow conditions there’s other aspects I’ve seen discussed like encryption, 2FA, password policy, and then the non-technical stuff like who has access to the data and do I have controls around ensuring they aren’t doing anything improper with it. And then I’d run the whole setup past Bubble support as well as a hired pro.

A couple of posts that I recall as touching on sensitive data questions include:

PS: and I am guessing there are regulations in different countries governing how sensitive info needs to be held, which may be why Bubble has this disclaimer in their privacy policy, so there could be a legal/compliance aspect to this as well:


Subject to the following paragraph, we ask that you not send us, and you not disclose, any sensitive personal data (e.g., social security numbers, information related to racial or ethnic origin, political opinions, religion or other beliefs, health, biometrics or genetic characteristics, criminal background or trade union membership) (“Sensitive Personal Data”) on or through the Bubble Service or otherwise to us.

If you send or disclose any Sensitive Personal Data to us when you submit user-generated content to the Bubble Service, you consent to our processing and use of such Sensitive Personal Data in accordance with this policy. If you do not consent to our processing and use of such Sensitive Personal Data, you must not submit such user generated content to our Services.


Yikes! Appreciate the resources Ed.

This topic was automatically closed after 70 days. New replies are no longer allowed.