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

ihsanzainal84 · 2024-12-22T16:07:01.972Z

I’m not bothered about the WU. What matters to me is understanding more about how Current User works.

I already get that client side WFs and elements will use clientside values unless it’s not already loaded. I’ve done my own observations on the network calls that my apps make, so I have been optimizing my apps based off this understanding for a long time already.

So I’ll narrow down my question:
In the docs referred a few posts up, I am reading it as “Current User is logged in the is checked server side”.

Does this apply only to server side or does this apply to client side conditions too? The section in the docs imply that it gets checked server side for client side.

petter · 2024-12-22T16:51:45.759Z

Well, I do get that perspective, and I agree WU has added a layer of complexity that can be confusing to both new and experienced users. Is that optimal? Maybe not, but implementing some charge for spending server resources was necessary to keep Bubble profitable in the long term.

So my point is not to discourage you from studying questions about charges; optimization makes sense, and to do that well you’ll need to stay informed. That said, I keep seeing some users becoming so focused on WU anxiety and granular optimization that the time, energy, and frustration involved often outweigh any meaningful benefits. As a new user, there are countless more important things to study up on to become a good developer and getting a great app to the market.

0,02 WU is about 0.0000114% of your total allocated 175k workload units on the 29 USD Starter plan. You could run that condition 8,75 million times per month before having to spend 26 USD to get an additional 200k WU and check the condition another ten million times.

It just doesn’t add value to optimize at that level. If it takes you no extra time, by all means, go ahead, but I see devs going down a rabbit hole of minutiae optimization attempts when there are are countless decisions that should have a much higher priority. At some point, we need to draw a line on what constitutes meaningful WU optimization. Beyond that line, the effort and mental energy spent on the process can become more costly—to your project and your piece of mind—than the actual financial cost of hosting.

When WU discussions becomes a game of “gotcha” to “reveal” that Bubble charges for some specific process, I just don’t find it that interesting. Bubble charges for all server processes, so I don’t really see what’s new.

Those charges may be granular, but, they’re still charges. They were important enough for Bubble to charge each and every person so they’re open to questions.

That’s where I think a shift in perspective is helpful to avoid being too caught up in details. If you go into WU optimization with the mindset that “here’s another process that Bubble has decided to charge for”, you’ll constantly be left frustrated and your project will suffer from it. Every server interaction is charged, with no exceptions, in the same way that your electricity company charges for every little lightbulb in your house – but you wouldn’t consider it a special “lightbulb fee”. It’s just a part of the total.

Most of us optimize our electricity use as best we can, but we accept that getting a full picture of where every kWh is going is too complex. We certainly don’t want to give up having a warm (or cool) house and the lights on at dinner time. Electricity is there to be used, and so is WU.

senecadatabase · 2024-12-22T17:07:01.862Z

Thank you for your response.

I respect your knowledge when it comes to Bubble.

All I would add is that after 10 years of working in the ‘traditional’ app building space, and having worked on teams with some of the most popular apps out there…

there isn’t another single platform with pricing so confusing.

And, in the no code space that’s geared for non technical people, it adds a whole level of complexity that isn’t shared by any other single platform in the no code space.

My company got an email from the oldest no code/low code platform a couple of days ago that said: ‘Bust the Bubble, not the budget’…referring to the meter that runs everytime a user logs into your Bubble app.

I think Bubble is a great platform…I’m not understanding the complexity behind the pricing though.

But anyway, thank you for your time in responding.

petter · 2024-12-22T17:45:06.621Z

Well, I wouldn’t really disagree with you on that point. I think it’s fair to say that the WU model is somewhat misaligned with Bubble’s vision of making everything simple.

But mindset does matter. It’s very easy to make it more complicated than it is. I too spent a lot of time in the beginning digging into specifics, but found that it had diminishing returns.

Most apps I look into for clients concerned about high WU spend can trace their problems back to one or a couple of runaway processes that really deserve optimization whether they cost WU or not.

I don’t tend to focus much on WU in my day-to-day work, and would encourage most users to have the same mindset. It’s worth learning the broad strokes of optimization, and to learn to use the metrics and logs to identify major culprits, but new users really should focus on building a high-quality, secure app with great UX. If everything in the learning and development process gravitates around WU, the app will suffer.

senecadatabase · 2024-12-22T18:03:11.433Z

Thanks for your response and also doing it in a professional manner.

I appreciate that you’re willing to give feedback on differing opinions.

georgecollier · 2024-12-22T19:22:34.517Z

petter:

I see devs going down a rabbit hole of minutiae optimization attempts when there are are countless decisions that should have a much higher priority

Bubble is cheap based on what you can do with it… just treat WU as cost of doing business (a business you wouldn’t be prepared to risk if you couldn’t build it cheaply with Bubble) and fry the big fish. 20% of workflows cause 80% of workload.

davidb · 2024-12-22T22:56:18.390Z

ihsanzainal84:

I’m not bothered about the WU. What matters to me is understanding

While this thread originated literally to point out a perhaps overlooked aspect of WU, @boston85719’s tip is in the context of broader discussion about security (as alluded to in the tip’s own title). That broader discussion has been prompted by several recent–and highly valuable–tips from @georgecollier focused on elucidating techniques critical to secure app development that are addressed either not at all or insufficiently precisely in the manual. Regardless of the relative (un)importance of understanding the granular WU implications of workflow conditionals, it’s of critical importance to understand the security implications.

boston85719:

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

petter:

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 think the core question to ensure is addressed in the manual both accurately and precisely is:

What technique(s) can a developer use to ensure that a workflow conditional is evaluated on the server, where it’s secure, instead of on (or, at least, only on) the client, where it’s subject to manipulation?

Various subquestions include:

For a conditional on a workflow’s event:
- What attributes of the conditional force server-side evaluation?
- What attributes of the event force server-side evaluation?
- What attributes of the workflow’s actions force server-side evaluation?
For a conditional on an action within a workflow:
- What attributes of the conditional force server-side evaluation?
- What attributes of the action force server-side evaluation?
- What attributes of the workflow’s event or its other actions force server-side evaluation?

georgecollier · 2024-12-22T23:11:46.007Z

davidb:

What technique(s) can a developer use to ensure that a workflow conditional is evaluated on the server, where it’s secure, instead of on (or, at least, only on) the client, where it’s subject to manipulation?

Treat any data stored in a group/state as insecure.
Any other condition involving data, or API calls (except in the rare case where they’re called directly from the browser) is secure. e.g Current User’s X or Do a search for Y is secure.

Don’t overcomplicate it - people are getting their knickers in a twist over something that doesn’t need an overwhelming amount of unpacking.

@petter ’s weakest link analogy is an easy way to understand it.

A server side action includes things like creating/modifying/deleting things, scheduling API workflows.

A client side action includes things like client-side plug-in actions, showing/hiding elements/alerts.

Group variables and states are client side data and are manipulatable no matter where they are used.

A server side action will have any server side components evaluated server side. Current User’s X and var - example’s Y will have Current User’s X evaluated server side, and var - example’s Y will be taken from the client (so you could manipulate Y).

This is and has always been the behaviour of Bubble, documented or otherwise, and mimics the normal behaviour of any web tech stack (re. evaluating permissions server-side).

So, if you want to restrict a workflow/action to admins:

use conditions like Current User’s Role is Admin or Do a search for Y.
treat any references to group variables or custom states as manipulatable.

That’s basically it!

randomanon · 2024-12-23T02:06:40.553Z

Sorry, to specify, I mean setting serverside conditions on “UI actions.” I’ll be more specific here since you can put server-side actions like “Make changes to a thing” on a front-end/client-side workflow event.

Putting serverside conditions on UI actions is bloat.

ihsanzainal84 · 2024-12-23T02:32:40.792Z

ihsanzainal84:

Does this apply only to server side or does this apply to client side conditions too? The section in the docs imply that it gets checked server side for client side.

Hey @petter it’ll be great to have an answer here. I’ll reframe my question since I think everyone who has replied to my post is taking my question under the context of WU charges.

I’ll make it clear now that my concern is about security not WU. It’s about the reliability of Current User is Logged In as a point of security since in the doc it states:

Conditions

Conditions can be processed directly on the client or needs to involve the server, depending on the dynamic expression that you use. If you use a condition on an important workflow event or action, it’s more secure to set up a condition that involves the server; that way, the processing is done out of reach of the user.

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.

Additionally, if the condition is placed on a server-side action, both the condition and the action will be processed on the server. The exception is if the condition can’t be processed on the server. For example, Element X is visible needs to be checked on the page, and can result in a more vulnerable condition.

I bring attention to the following:

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.

The doc implies that Current User Is Logged In will be checked (or involve) server-side when used in a client-side event or action. I garner this based off the following paragraph:

Additionally, if the condition is placed on a server-side action, both the condition and the action will be processed on the server. The exception is if the condition can’t be processed on the server. For example, Element X is visible needs to be checked on the page, and can result in a more vulnerable condition.

In summary the section I refer to implies that Current User Is Logged In is a good way to secure an Event. Can you confirm this?

A lot of your responses talk about server-side WFs to keep things secure. I understand that. My next bunch of apps require stricter security. I can always add my own layer of authentication off of Bubble if my clients require but it’ll be much easier (less work to do) if I can assure them the above is true and it’s not just me talking out of my ass.

ihsanzainal84 · 2024-12-23T02:44:36.913Z

It’s not about overcomplicating things.

We all build for clients. Clients need assurances. I can’t have something that is documented not work the way it is implied. My next set of apps have to go through government scrutiny. I barely scraped by with my last government funded app in regard to security.

We all also build with cost considerations. While I do not fret the nitty gritty WU costs, I always plan for the bigger picture. Costs can also come from external services. Costs also include my time. If a simpler approach can save me any of these costs, I’ll go for a simpler approach.

boston85719 · 2024-12-23T04:38:00.532Z

Firstly, thank you for replying. I’ll try to orient things for clarity.

The concern is not about putting a conditional onto a specific action, whether it be client side or server side. The concern is about putting a conditional onto an event trigger, and anywhere else and whether or not that conditional is evaluated on the server Illustrated below.

The concern is this:

Screen Shot 2024-12-23 at 11.31.34 AM341×405 18.6 KB

Screen Shot 2024-12-23 at 11.31.06 AM341×296 14.7 KB

On the Event Trigger (ie: the button is clicked, not an actual action) or on the element, both use the same condition, of current user is logged in. So, do these conditions get evaluated on the server as the manual indicates.

For reference to the manual: Use the Link scroll to Conditions section

Screen Shot 2024-12-23 at 11.33.15 AM1010×667 50 KB

and focusing on this excerpt:

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.

In my post I use the phrase ‘force server side evaluation’ which for me, is the same meaning, just different words, as ‘to make sure a condition is processed server-side’.

That I think is the main issue that needs to be addressed, as once it is all else can be hashed out.

A secondary concern, is, if that condition does in fact force a server side evaluation of the condition, what data needs to be passed from client to the server that would result in an individual data request charge of 0.02 WUs.

randomanon · 2024-12-23T08:05:48.086Z

boston85719:

On the Event Trigger (ie: the button is clicked, not an actual action)

Doesn’t matter if you use a serverside or clientside condition, it can always be bypassed since the event trigger is client side.

So if you care about .00002 WU (but more importantly the wasted lines of code), feel free to delete any serverside conditions on that event trigger.

georgecollier · 2024-12-23T08:39:50.174Z

randomanon:

Doesn’t matter if you use a serverside or clientside condition, it can always be bypassed since the event trigger is client side.

No, not right - if you manipulate the condition, here’s what actually happens (if the workflow has at least one server side action):

Trigger fires
Bubble checks on their server
Bubble returns ‘event failed’ error for the workflow

randomanon · 2024-12-23T08:54:45.105Z

georgecollier:

No, not right

georgecollier:

if you manipulate the condition

georgecollier:

Trigger fires

???

My point is that you can’t secure a client side trigger event like “button is clicked” no matter where the condition is being evaluated.

georgecollier:

if the workflow has at least one server side action

This is the only thing that can possibly be protected.

petter · 2024-12-23T08:55:25.730Z

It will always be a weakest link situation.

To complete the weakest link illustrations from my book any scenario with a red lock cannot be considered secure:

CleanShot 2024-12-23 at 08.53.37@2x1278×464 42.2 KB

Example: Group A is visible -> Make changes to user

CleanShot 2024-12-23 at 08.56.11@2x1280×418 38.9 KB

Example: Current user is logged in -> Show Group A

CleanShot 2024-12-23 at 08.57.27@2x1230×444 44.5 KB

Example: Group B is visible -> Hide Group A

CleanShot 2024-12-23 at 08.58.37@2x1194×454 37.6 KB

Example: Current user is logged in -> Make changes to a thing

Whether a condition is “forced” to be evaluated on the server or not is still only relevant if the action happens on the server. All client-side actions are insecure, regardless of where the condition is processed. This is true even if the workflow contains both server-side and client-side actions (the server-side actions will be secure, the client-side actions will still not).

This article in the Security section and this article in the Workload section go into more detail about what is processed where.

Why current user is logged in is secure
When you use a condition like “Current user is logged in” (even on a backend/server-side workflow), Bubble validates the user’s session token server-side rather than purely trusting a client-side cookie value. Here’s how it works under the hood:

Session token

Bubble uses session tokens. When the user makes a request to run a server-side workflow, Bubble checks the validity of that session token:

Is there a session token being sent with the request?
Does that session token match a currently valid session in Bubble’s system?

If the token is invalid or missing, Bubble treats the request as not authenticated.

Why it’s hard to “fake”

A malicious user can’t simply manufacture a valid session token, because:

The tokens are cryptographically generated and in principle impossible to guess.
Bubble expects that token to match a valid, active session on the server.

If someone tried to copy another user’s cookie, they’d need direct access to that user’s browser/computer or intercept it over an unencrypted connection. Since tokens are transferred over HTTPS, they are very difficult to intercept. Once a malicious actor has gained physical or direct access to a user’s device, they could copy any stored cookies or session tokens, effectively impersonating that user—regardless of how secure Bubble (or any other server-side system) is. At that point, the threat is at the device level, and server-side security can’t mitigate a locally compromised environment (except to allow the user to log out of all devices).

This is not a Bubble-specific limitation but a general principle of cybersecurity: if the endpoint itself is compromised, the security of the underlying application is effectively bypassed.

randomanon · 2024-12-23T08:57:43.254Z

petter:

CleanShot 2024-12-23 at 08.56.11@2x1280×418 38.9 KB

Example: Current user is logged in -> Show Group A

This is what’s tripping these guys up.

petter · 2024-12-23T09:05:58.630Z

I’ve expanded the section about conditions to strengthen this point.

Regarding your point above @randomanon, the best way to explain this (I think) is that the action (Show group A) needs to be processed on the client, since the server has nothing to do with element visibility – it’s part of the on-device code. As such, Bubble can check the condition (Current user is logged in) all it wants, but the visibility of that element can still be tampered with in the user’s device. This is not because the condition fails to be checked, but because the action is executed with client-side code.

I use another illustration and metaphor in my book to visualize this:

CleanShot 2024-12-23 at 10.01.09@2x950×798 20.2 KB

CleanShot 2024-12-23 at 10.01.57@2x1306×878 124 KB

Everything that reaches the user’s device is insecure. Elements can be made visible/invisible, moved and re-styled. However, as long as privacy rules are there to protect your data, the page should be like an empty room: the walls are there, but there’s nothing of value to be found.

While this is meant to explain privacy rules, it’s true for client-side actions as well. There’s nothing Bubble can do to stop client-side actions from running, even with server-side conditions, since the logic rests on the user’s device.

georgecollier · 2024-12-23T09:10:35.406Z

randomanon:

My point is that you can’t secure a client side trigger event like “button is clicked” no matter where the condition is being evaluated.

Almost every trigger in the front-end is client-side - you can still secure the workflows associated with them.

For example, Button is clicked and Create a new thing is secured by Current User’s Role is Admin, is secure. A user will not be able to create a new thing unless they’re actually an admin.

Just because the trigger fires and the workflow starts, doesn’t mean Bubble runs it. ‘Workflow starts’ means a request is made to Bubble to start it, at which point it checks the conditions server side when deciding whether to continue. If the condition isn’t met because the user manipulated it, it returns an ‘event failed’ error.

adamhholmes · 2024-12-23T09:46:08.944Z

boston85719:

Screen Shot 2024-12-23 at 11.31.34 AM341×405 18.6 KB

That’s an element which, obviously, is rendered on the client.

Therefor the condition is checked on the client.

Screen Shot 2024-12-23 at 11.31.06 AM341×296 14.7 KB

On the Event Trigger (ie: the button is clicked, not an actual action) or on the element, both use the same condition, of current user is logged in. So, do these conditions get evaluated on the server as the manual indicates.

As has been explained already…

For client side actions the check is made on the client (how could it possibly be otherwise?)

And for server actions the check is done on the server.

boston85719:

That I think is the main issue that needs to be addressed, as once it is all else can be hashed out.

I’m still not sure what the ‘issue‘ is here, or what exactly needs to be addressed or hashed out.