Forum Academy Marketplace Showcase Pricing Features

Should we try to run security workflows before anything else on page load?

We’ve set-up a series of a workflows that we’re running on every page to check whether someone has permission to access the page. Would it make sense to try to run these before other workflows, before html/css loads, etc.?

Seems like it’d be better security to run them first, but seems like it’d slow down page loads for the 99% of users who are going to a page that they have access to.

How have you thought about this for your app?

I’ve started using a blank page with redirects. I have an app with teachers, school admins, and district admins, and they share the same links. It goes to a blank page, figures out who they are, then redirects with the appropriate parameters. It all happens really fast, almost not noticeable.

1 Like

When happens if a user with bad intent tries to go directly to pages where they shouldn’t have access? If you don’t have page-level security on that page, then they’ll be able to access it. Right?

In my case, they don’t actually have any of the data that makes the page useful unless they were intended to go to that page in the first place. District admins don’t have the same data available to them as teachers, so they can go to the page it’ll just useless.

The method I use doesn’t work for all cases, of course, and sounds like a better/more secure method might be needed for ya. I also like to assume/pretend the people that find my very small app aren’t filled with malicious intent :stuck_out_tongue:

Yeah, makes sense.

Yeah, we’re locking down our database as it sounds like you’ve done. I also want to lock down pages as well as workflows that impact our database as additional layers of defense. Bubble makes it so easy enough to set-up that it’s a no brainer for us to spend the time to do it right with our app.

I’m sure 99.9% of people aren’t going to do anything malicious, just want to make it hard on anyone who even considers trying.

I currently use:

  1. Page Redirects via workflow
  2. Conditional statements on a container that displays the page when requirements are met
  3. Data privacy settings.

Currently, all three of these things happen extremely fast in tandem. Let’s see what happens as our user base continues to increase :wink:

2 Likes

Hi SuperNaturally. I’m struggling with techniques to secure pages from malicious users who could potentially copy/paste URL’s in my app to see data they’re not supposed to. I’ve got some Page Load workflows, but it seems like the logic runs AFTER the page loads, so for a split second, a malicious user could see info their not supposed to. Could you elaborate on your use of Conditional Statements and Data Privacy settings? Any help would be greatly appreciated.

1 Like

@greenmerits

You should first use Privacy settings inside of the Data tab:

If you define user roles and attach them to a user (ex. create data type on “User” called “admin”…make it a yes/no field), you can use the above section to define specific data fields that are visible for that person (i.e when “admin=yes”). Even if you have elements on the page that are visible when someone visits the URL, the data will be blank if they do not meet the conditions you define.


If you want to make your elements ‘invisible’, just uncheck “This element is visible on page load” for all of them, and THEN define conditional statements that make them appear (i.e. when “admin=yes” this element is visible, etc…the same condition that you define in the Privacy section). A better approach might be to group all of the elements on the page into a single group, then make that group invisible on page load with the condition that ‘when admin=yes’, the element becomes visible.

Does that help?

1 Like

This helps somewhat, but I believe the underlying problem remains. Even if I create a role called “Users” in the Privacy section, once someone has registered to use my site (and is in fact a legitimate user), for some reason, they can still view data that belongs to another user. For example.

Two users Frank (good guy) and John (bad guy) - they work together at the same office and both have their own logins for my site. Frank logs into a shared computer at the office and uses my site. When done though, he forgets to log out and/or clear his browsing history.

John then comes in and uses the same computer Frank was on. He logs into my site with his own credentials, and (maliciously) goes through the browser history and clicks on the same pages Frank was on previously.

Bubble allows John to see Franks info as both of them are valid users, but John is using the browser history to see data that he was not supposed to be looking at or have access to.

While unlikely, this is the scenario I’m hoping to prevent using workflow. I’ve created a PageLoad that checks the current user to see if they are the owner of the data appears on the page, but again, Bubble loads the page first and then checks the condition. Wish there was a “PageLoading” (which took place before rendering actually started).

See where I’m coming from with this request though?

1 Like

If I understand correctly, you’re concerned about information being accessable until after pageload?

There is not much you can do if someone forgets to log out. However, if John logs into your site with his own credentials - if his user account doesn’t have “admin=yes” (or some similiar privacy setting), he will not be able to view any of the data. These privacy settings are set before pageload. Only conditional statements (i.e. a conditional on an element) occur after page-load, so even if an element appears for a second, the data inside of it will not. (example: you might see Frank’s user settings, but his picture, email, phone, name, etc. will be completely blank…making his account and his info unidentifiable)

For visual effect, just encapsulate everything into a single group…uncheck ‘visible on pageload’…then set a workflow to check the user’s credentials (i.e. does “admin=yes”). That way you’ll have privacy around data (before page load), and nothing will be visible after pageload unless the user meets the criteria you specify.

1 Like

Gotcha. I think I’ll give try the approach regarding putting everything into a group and making it invisible. Thanks for the idea/help! Really appreciate it.

@greenmerits – Following your thread from above.

Summarizing: We’re all solving a similar problem = The page loads before the 1st workflow runs to check if user has permission to access the page. So, if the user types a URL directly, they see the page load/partially load before they’re kindly redirected if they don’t have access.

The alternative you suggest is to put everything on every page in a group and have that group show only when the user has the right permissions.

Curious if you’ve done this and if so how’s it working for you?

From the outset it seems like we would be better making a feature request from the Bubble devs. Your idea, while doable, is more workflows (general slowness) and not a great user experience because of the UI blips (still has page load -> redirect)

Hi @kramwe. I’m working on a few other things currently and am going to revisit implementation of this. I wish there was a slightly more elegant way to check conditions prior to page fully loading, but it seems the only option is to group everything on the page and check the condition.

You can overcome the loading ‘blip’ by using a similar UI to any major software.

Think of Gmail or Slack, when they first load the inbox doesn’t appear instantly. There is a loading page usually with a logo or progress bar. You can also load a random witty quote if you want. You’re right in thtat people do not want the delay, but if you use a good UI people will be fine with it.

To do it, put a “Loading Group” visible on page load, and then use the Security workflows to either navigate to a new page or hide the Loading Group and show the correct group. You can also do this for pages that load a lot of data and take a while, by showing the loading screen while the repeating groups work in the background

Interesting… Do you have an example? I anticipate we’re all solving for this issue.

This template shows the idea behind it, but doesn’t actually perform a security workflow at the end. It is just a visual example of a loading screen

Some Slack examples:

Okay. We’ve implemented some logic to handle wait times, but this doesn’t tackle page-security. If someone hits a URL they don’t have access to, the page partially loads before s/he is redirected.

Some security suggestions based on what we’ve posted about…

ONE
Have 2 master groups on the page.
‘Loading Group’ - visible on page load (this group has a loading icon and message)
‘Admin Group’ - invisible on page load (this group has all page info)

Add 2 workflows…
On page load - When Current User’s Type is “Admin”
-> Hide ‘Loading Group’, Show ‘Admin Group’

On page load - When Current User’s Admin is not “Admin”
-> Navigate to index

This way if someone hits the URL they will see a quick loading page, and then be redirected away from the page before being able to see any of the page they do not have access to

TWO
Use Privacy Roles set on the data (under the Data tab). That way if someone does manage to stay on a page they shouldn’t be on, and gets around the work from above, no data would actually show

THREE
Put conditions on every button you want secured
When Button A is pressed and Current User’s Type is “Admin” -> run the action
When Button A is pressed and Current User’s Type is not “Admin” -> go to page index

We’ve done similar as it seems this is the only option available to us.

The page-level security doesn’t seem all that secure though since sometimes the content loads for a bit before redirect (so only DB security is left to prevent bad things). This means pages can likely get indexed by bots even when page level security is designed to prevent that. So, feels like a lot of extra security work for little feeling of comfort.

Furthermore, we also have to add security on buttons since page-level security isn’t reliable. Making sure every sensitive button is secured is quite tedious to implement and even more so to maintain. After all, how many of us actually go through and test the security of all the buttons we create (so one mistake and that layer of security is penetrated).

Would be nice if page-level security just worked.

6 Likes