Hard Fact - Securing your App with Server Side Conditionals Costs 0.02 WUs

I don’t know anything about the ‘bug’ you’re referring to here… but just to clarify a few things.

That condition IS evaluated sever-side.

There is NO difference between Current User Role Is Admin and Current User is Logged In And Current User Role Is Admin in terms of where the condition is evaluated (sever or client).

Current User is Logged In can be manipulated on the client just as easily as Current User Role is Admin, for use in client-side action conditions.

(so too can search for users count > 0)

Client-side actions based on data that’s already loaded on the page will evaluate conditions based on that client-side version of the data.

(note: conditions for client-side actions which involve data NOT already loaded to the page will first load the relevant data to the page BUT the conditions will be evaluated on the client-side, so that data is still open to manipulation)

But all that’s irrelevant, as server-side actions evaluate data for conditions on the sever, and so are immune to any client-side manipulation.

i.e. Current User's Role is Admin is evaluated on the Sever, just the same as Current User is Logged In and Current User's Role is Admin when being used as a condition on a server-side action (or a WF that contains server-side actions).

So there should be no difference in the WU cost between those 2 conditions.

I just ran another test to confirm this, this time using Current User is Logged In and Current User's Role is Admin and got exactly the same results as before (as expected)…

i.e. again, as expected, for a client-side only WF there is NO additional WU cost to evaluate the condition, as the User data is already on the page.

For a WF with sever-side actions, a WU of 0.02 is incurred which, again, is exactly what’s expected to retrieve the relevant User data in order to evaluate it.

If you’re seeing different results to that, then I suspect there is some other source of the WU coming into play here.

Your assumption that using current user is logged in and current user role is admin somehow forces the condition to be evaluated on the sever (whether there are server-side actions or not) is simply untrue (and easily testable).

As I’ve explained client-side WF actions will evaluate any data-based conditions against the client-side versions of that data. (e.g. the condition current user is logged in and current user role is admin is evaluated client-side for any client-side actions in the WF).

Server-side actions always evaluate conditions on the server (unless they are based on conditions the server doesn’t have access to).

It’s just as easy to manipulate the Current User is logged in condition on the client side as it is to manipulate Current User's role is Admin.

But, again, that only affects client-side actions.

2 Likes

Okay, so this page from the manual and this snippet from the page is untrue, or I’m misunderstanding it?

The Bubble manual is just giving 2 examples of expressions which use server-side data (i.e. a check of the Current User and a Database query).

But… the Bubble manual does not mention that those conditions are only checked on the server for server-side actions.

Of course, client-side conditions (such as element visibility and/or client-side actions) are evaluated on the client (and can therefore be manipulated, no matter what the condition is).

So the manual is not wrong as such - it just doesn’t necessarily give the whole picture.

1 Like

No, but it says that in order to make sure a condition is processed server-side, which for me would mean, that the condition is getting evaluated server side. I also says that both conditions, Bubble will query the server to process, so I read that as stating, it forces the condition to be evaluated server side.

Of course, it is hard to determine exactly what the phrases are meant to mean if they are open for interpretation. @petter could you shed light onto this statement: To make sure a condition is processed server-side, you can involve anything having to do with the database or user authentication. For example, Current User is Logged in and Do a search for:count>0 are both conditions that Bubble will query the server to process.

@adamhholmes my assumption is that this is akin to forcing a server side redirect versus client side redirect, where using current user is logged in as a condition on the page is loaded forces a server side redirect, because that condition is processed server side. My thought is the same logic applies in terms of a condition like ‘current user is logged in’ being processed server-side in other cases besides navigation, as I believe navigation is client side action and not server side action.

2 Likes

A condition will only be processed on the server if it involves a server-side action.

That shouldn’t be surprising.

1 Like

Okay, so you would then state the manual is wrong or just poorly worded.

@boston85719 The key thing to understand is that whether a condition gets evaluated server-side or client-side depends on the action being protected, not the condition itself. You’re getting client/server-side conditions confused with client/server-side actions.

If you put “Current User is Logged In” on a client-side action (like showing an element or an alert), the condition will be evaluated client-side using the data already in the browser - no matter what condition you use.

If you put that same condition on a server-side action (like creating a thing), then yes, it gets evaluated server-side and costs 0.02 WUs because the server has to verify it. Behind the scenes, your browser gets the data, verifies it can run the workflow, and Bubble also checks that on their side. That’s what doesn’t happen with a client side action/workflow.

So, when the manual says certain conditions are “processed server-side,” as @adamhholmes correctly points out, that’s only true when they’re protecting server-side actions. You can’t force client-side actions to evaluate conditions server-side - that’s just not how the architecture works.

Anyway, what does that mean for you? Client-side actions can always be manipulated no matter what condition you use (as they can on basically any other development framework).

Conditions on server-side actions are secure (with that one logged-out exploit being patched soon) because their conditions are always checked server-side before executing.

Basically, don’t worry about it. You don’t need to pull user is logged in and user is X and do a search > count > 0 gymnastics to make workflows secure.

As a clear example:

  1. Button ‘delete things’ triggers workflow with two actions - ‘Delete a list of Things’ and ‘show an alert’
  2. A condition Current User’s Role is Admin is on the workflow event
  3. Current User is not admin
  4. User manipulates their data to set their role to Admin and runs the workflow
  5. The workflow runs, but Delete a list of Things (a server-side action) returns an error because Bubble has checked and the user isn’t actually an admin. The alert, a client side action, shows, because Bubble doesn’t check this on their servers, as it’s just a client action and doesn’t interact with Bubble’s servers.

The front-end evaluates this client side action’s condition itself using the data returned from the database. Bubble evalutes the server-side action’s condition in its own servers in addition to what’s been sent to the user to verify that it can/cannot run a particualr action.

3 Likes

I guess my confusion comes from me putting a condition on the event trigger and not the action itself, so my thought was that if the event trigger has the condition, it makes no difference what actions are part of the series, that the condition would be processed server side as the manual states. I was under the assumption, Bubble must first process the condition on the trigger to know if the trigger should even ‘fire’ or ‘execute’ and that they would not be looking at the actions within the series to determine if the condition on the trigger event needs to be processed server side or client side.

Probably also my confusion comes from the difference between page redirects as client side or server side where we can force a server side redirect with the condition on the workflow trigger event of ‘current user is logged in’ because that condition gets processed server side. I would have thought the same logic applies to workflow trigger events like a button click, that regardless of client side or server side actions in the series, it is the condition itself on the trigger that gets processed server side.

The 0.02 WUs attributed to individual data request is for what data, the current user? I thought current user was already downloaded on page and doesn’t cost anything and the same being true on servers.

I’m going to agree with @boston85719 on this one. The wording in the documentation clearly implies that an expression like Current User is logged in, when placed in a condition, will be processed server side regardless if the Current User is already loaded clientside and regardless if placed in a client side or server side WF.

If otherwise then it means the documentation is wrong, outdated or it not calling serverside is a bug.

3 Likes

I agree that, whatever the precise behavior and associated explanation are, the manual is not just incomplete but unclear.

A potentially relevant factor that I don’t see explicitly disentangled yet in the thread is whether the workflow event itself involves the server–e.g., Page is loaded depends on the server while Element is clicked does not. Maybe the preceding quote from @georgecollier about actions applies equally to events.

1 Like

Could be…bubble support confirmed the behavior and kicked it up to engineering for investigation. So, should get an explanation and fix of some sort soon enough.

I’m happy to clarify stuff in the manual if it’s unclear. I’m looking through now, but feel free to point me towards specific points/sentences.

I’m not sure I entirely understand the premise of the question, but I may be missing something; client-side workflows are insecure period, regardless of where the condition is processed. A skilled attacker can always manipulate client state in a way that bypasses client side conditions (since they have complete 100% control over what gets executed on their device), and could spoof the result of a network call to emulate a server-side condition being approved.

I.e. everything happening on the page is insecure, and all conditions, whether on elements or client-side workflows, are ways to obfuscate (and building a UX that makes sense), and not secure.

Workflow execution operates by first checking on the client side whether the event condition is met. If it passes and includes actions requiring server-side processing, the server is then prompted to execute the workflow. The server subsequently re-evaluates the event condition, and if it still passes, the server proceeds to execute the workflow.

In my security book (I know it was the manual you mentioned, but thought the illustration might be useful to some), I illustrate it with a “weakest link” visualization:

5 Likes

It still not clear to me exactly what the ‘issue’ is here… or what needs to be ‘fixed’? (Or in what way the current behaviour could be changed, or why it needs to be?)

Unless you’re specifically asking why there seems to be a data request made (and therefor WU incurred) every time a condition is evaluated on the server (suggesting there should be some session-based data caching on the server - which could definitely reduce WU cost, but would introduce its own set of problems, unless we had full control over its use).

1 Like

This is a good idea.

@boston85719 the only take home that really matters with respect to security for you is that Bubble does evaluate conditions as you’d intuitively expect.

Worried that the client side workflow is insecure? It’s client side, so they can execute it anyway (if it shows an element, they can force that element visible anyway).

I think you’re also getting muddled by the idea of ‘current user is always loaded on the page, so why is it fetched again?’. It’s loaded on the page. Bubble still needs to check it on the server before running the workflow if your condition involves it.

Want to secure an admin workflow? Add Current User’s Role is Admin as a workflow event condition - I don’t think there’s much more to say than that.

2 Likes

Does Current User field value get checked client side (based off the Current User data that is already loaded on page) or having it as a condition force a server side check?

Same question for Current User is Logged in

They’re checked on the client-side for client-side actions…

And on the server for server-actions.

1 Like

Again, it depends on the specific action. For a process or condition that is purely client-side, Bubble can only perform checks on the client-side, as adding server-side validation wouldn’t enhance security. While I can’t say for sure if they actually do rely solely on client-side confirmation in every case where they could, from a security standpoint, it doesn’t make any difference.

For server-side actions, the condition is always re-evaluated on the server, which is of course necessary for security reasons.

Regarding the concern about potentially unnecessary WU usage (e.g., 0.02 WU), I personally don’t see significant value in scrutinizing WU consumption at such a granular level. I wouldn’t call it a bug that Bubble checks a server-side condition on the server – even if it’s technically unnecessary to do so. Your app will continually communicate with the server for all sorts of reasons, and yes, every interaction has a slight cost. Maybe Bubble will optimize that corner case, but I wouldn’t hold my breath, and I’m not sure that’s where I’d want their engineers to spend their time.

Shifting server-side checks to the client in various edge cases, could save WU, but also theoretically introduce vulnerabilities that may compromise security if something is overlooked. As such, I see it as prudent to err on the side of caution by maintaining server communication more frequently rather than risking insufficient validation.

I completely understand and respect that users (myself included) are striving to optimize WU usage and provide feedback to Bubble when there are disagreements. That said, there are likely many scenarios where one could argue that server involvement might not be needed, but I personally feel that focusing on waste at such a negligible level is not worth the frustration. My intention is not to dismiss anyone’s viewpoint but to emphasize that the time and effort spent continually optimizing WU consumption at minutiae levels also comes at a cost—diverting attention and energy away from other valuable pursuits.

As always, these are my personal reflections.

4 Likes

Yup… it’s really not worth the time

This

And this

…are kind of all you need to concern yourself with if your primary concern is security. And if you’re concerned about the 0.02 WU, then I can’t help but feel that it’s an insult to the value of your time :man_shrugging:

2 Likes

Why are people ignoring this?

Client side conditions are only for UX purposes.

WU notwithstanding, it’s extra lines of code you don’t need, it’s just bloat.

1 Like

This may be true…

but it also leads me to question why we’re charged for everything on such a granular level.