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

[adamhholmes]

@randomanon

Why are people ignoring this?

@randomanon

I think the takeaway here is that it’s pointless to have those conditions on your regular workflows because a client side action can be bypassed anyway.

I wouldn’t say that…

Conditions on sever-actions in ‘regular’ workflows are checked on the server, and can’t be bypassed (and are therefore secure)…

(assuming, by ‘regular’ workflows, you mean Page Workflows?)

Bubble blurs the lines a lot between client-side and server-side actions… which often leads to confusion, especially with newer users…

Page (or ‘regular’) workflows usually contain a mixture of client-side and server-side actions…

Client-side action conditions are checked on the client, server-side action conditions are checked on the server.

So putting conditions on Page (regular) workflows is perfectly secure, and definitely not pointless.

[petter]

This may be true…

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

I really can’t get into that mindset or see the logic in it. Bubble charges for all the work that the server does. Why would it not include small tasks?

[senecadatabase]

My point is, if they charge you on a granular level, it’s expected someone would question granular level charges.

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.

My main contention is even those who have years of experience with Bubble are trying to figure out all the things they’re charged for.

It’s confusing to say the least to new users like myself.

I personally get something out of each question about charges.

Anyway, thank you for taking the time to reply.

[ihsanzainal84]

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]

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]

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]

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]

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]

@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]

@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]

@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]

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]

@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]

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]

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

1. 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:

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

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]

@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]

@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):

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

[randomanon]

@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]

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:

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

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

Example: Group B is visible -> Hide Group A

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]

@petter

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

This is what’s tripping these guys up.