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

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.

randomanon · 2024-12-23T09:51:32.438Z

georgecollier:

and Create a new thing

That’s the only thing being secured.

Not:

georgecollier:

Button is clicked

For Workflows without serverside actions you will never see a “Workflow starts” in your logs. No need to keep repeating this weird verbal sleight-of-hand.

ihsanzainal84 · 2024-12-23T11:37:41.196Z

No it’s not, at least it’s not mine. My base for building security comes from controlling what data gets loaded into the browser in the first place.

My concern is how the documentation presents itself within surrounding context. It’s important to me because of my clientele. It can also help reduce the complexity of my work.

@petter thanks for detailed explanation about howCurrent User is Logged Inworks. That’s what I wanted to know.

boston85719 · 2024-12-23T13:11:10.076Z

Thanks @petter. From the reply, it seems the manual is correct in the statement, that ‘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 and Do a search for:count>0 are both conditions that Bubble will query the server to process’

I just want to simplify this to ignore all the noise for a bit.

When the condition ‘current user is logged in’ is placed onto a workflow event trigger, and that event trigger has zero actions like the screen shot below…is the condition of ‘current user is logged in’ processed server side?

Screen Shot 2024-12-23 at 8.06.39 PM606×347 23.7 KB

georgecollier · 2024-12-23T14:36:56.062Z

boston85719:

When the condition ‘current user is logged in’ is placed onto a workflow event trigger, and that event trigger has zero actions like the screen shot below…is the condition of ‘current user is logged in’ processed server side?

Client side, because there’s nothing for the server to verify.

adamhholmes:

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

That shouldn’t be surprising.

And, to make the above even more explicit:

Server side actions/events have conditions evaluated server-side, where they cannot be manipulated
Client side actions/events have conditions evaluated client side using data FROM the server (which is prone manipulation)

I just don’t see what there is to be confused about.

If you want to securely restrict actions to certain users, use conditions that reference database data like Current User or Do a search for, and assume that states/group data can be manipulated. That’s it - that’s all one needs to know to secure workflows.

boston85719 · 2024-12-23T17:15:26.263Z

georgecollier:

Client side, because there’s nothing for the server to verify.

boston85719:

it seems the manual is correct in the statement, that ‘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 and Do a search for:count>0 are both conditions that Bubble will query the server to process’

georgecollier:

I just don’t see what there is to be confused about.

Why would it verify client side if the conditional is ‘current user is logged in’ and the manual correctly states that it is a conditional such as ‘current user is logged in’ that is ensured of being processed server side?

adamhholmes · 2024-12-23T17:40:59.081Z

boston85719:

Why would it verify client side if the conditional is ‘current user is logged in’ and the manual correctly states that it is a conditional such as ‘current user is logged in’ that is ensured of being processed server side?

Why would it verify it server-side if there is no sever action to process? (and even if it did, what would be the point? It wouldn’t make it any more secure - although that’s really not relevant - there’s nothing to secure here anyway).

Client-side triggers evaluate conditions on the client-side (how else could it?).

And why does it even matter?

boston85719 · 2024-12-24T06:11:30.421Z

adamhholmes:

Why would it verify it server-side if there is no sever action to process?

Because the manual says it would.

As a bit of background on this. I am a native english speaker and I taught English as a Second Language for 10 years. My mind is such that I am a learner through books first, conversation second and video/image last. The text in the manual is clear, that the example condition of ‘current user is logged in’ is processed server side. The manual should be accurate as it is the only public source of how Bubble works that comes ‘from the horses mouth’ and I personally rely on it’s accuracy to help form my understanding of how Bubble works and allows me to use logic to form ideas of how to best build in Bubble and what types of features Bubble should implement to make building more efficiently easier, as well as to not incur costs that can be avoided based on my decisions about how to build.

In case you missed it, this is the exact statement from the manual:

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.

To help illustrate how that statement is interpreted by a person like myself who is quite literal and I believe words have meanings that can for the most part not be left open for interpretation, here are five other ways this can be written provided by ChatGPT:

Here are five rewritten versions of the sentence:

To ensure a condition is handled on the server side, you can incorporate elements related to the database or user authentication. For instance, “Current user is logged in” and “Do a search for: count > 0” are conditions that Bubble processes on the server.

Server-side processing of a condition can be achieved by including aspects tied to the database or user authentication. Examples include “Current user is logged in” and “Do a search for: count > 0,” both of which Bubble evaluates on the server.

To guarantee a condition is processed by the server, include features involving the database or user authentication. For example, “Current user is logged in” and “Do a search for: count > 0” prompt server-side queries in Bubble.

If you want a condition to be processed on the server, make sure it involves database operations or user authentication. Conditions like “Current user is logged in” or “Do a search for: count > 0” will trigger server-side processing in Bubble.

To make sure Bubble processes a condition server-side, tie it to the database or user authentication. For example, “Current user is logged in” and “Do a search for: count > 0” are handled by the server.

All of these statements, the one from the manual and the 5 rewritten examples by ChatGPT seem to imply pretty clearly in no uncertain terms that the condition of ‘current user is logged in’ will be evaluated/processed server side. In that statement there is not ambiguity and is not possible to be open for interpretation.

So @adamhholmes and @georgecollier would you guys say that the manual is either incorrect or not clearly worded based on your understanding of how the conditional evaluation of a condition like ‘current user is logged in’ actual works?

Now, to help illustrate this further, once I use ChatGPT to read the entire page in the manual found at this link I get a more clearer view of the issue here. What ChatGPT says is ‘current user is logged in’ is not always processed on the server (which would point to the manual being inaccurate or written in a way that obviously can cause confusion for some people), while the condition of 'do a search for count >0 is always processed via the server.

Question 1: If I use a condition like ‘current user is logged in’ on a client side action, will the condition be processed on the server?

Response: No, if you use a condition like “Current user is logged in” on a client-side action, it will not be processed on the server. Client-side conditions are evaluated within the user’s browser, which means the processing happens locally rather than on the server.

For conditions to be processed on the server, they typically need to be tied to server-side elements, such as database queries (e.g., Do a search for: count > 0 ) or workflows explicitly designed to run on the server. The “Current user is logged in” condition can be evaluated either on the client or server, depending on where and how it’s implemented, but in this case, a client-side action will evaluate it on the client.

If you want the condition to be evaluated securely on the server, you should integrate it with a server-side workflow or database-dependent logic.

Question 2: If I use a condition like ‘Do a search for: count >0’ on a client side action, will the condition be processed on the server?

Response: Yes, if you use a condition like “Do a search for: count > 0” in a client-side action, the search itself will be processed on the server, even though the action is client-side.

Here’s why:

Database-related conditions: When a condition involves querying the database, such as checking if a search result count is greater than 0, Bubble will process the search query on the server. The server handles the query to retrieve or count the data from the database, and the result is then returned to the client for evaluation.

Security considerations: Even though the query is processed on the server, the logic and subsequent actions after evaluating the condition are still executed client-side. This means sensitive information or business logic should not rely solely on client-side validation for security.

To summarize, the search query (Do a search for: count > 0 ) is processed server-side, but the overall action remains client-side. If you’re concerned about security or integrity, ensure that sensitive conditions are handled as part of server-side workflows.

So in my quest to understand what is the most secure condition to use, one that can be used universally on every trigger event that may contain a server side action, I personally want to understand this 100% and not half-heartedly. One of the reasons why I want to put the conditions onto the trigger event instead of the action step itself is to avoid bloat, as many times a single event trigger will have multiple server side action steps involved in the series, so adding the condition to each action step in the series is nonsensical to me personally, and I’d rather just put the condition onto the event trigger and not worry about trying to secure each individual workflow action step as that would be more tedious, time consuming and prone to error as it is more likely I may forget to secure one of the action steps, especially since in the view of workflows I do not see at a glance the conditions of every action step but I can for every event trigger.

So, again using ChatGPT to get a better understanding of this, it seems that the manual can be updated to be more clear and based on ChatGPT responses, more accurate.

Question 3: What is more secure, a condition of ‘current user role is admin’, ‘current user is logged in’ or ‘do a search for count>0’?

Response: The security of these conditions depends on how they are processed and the context in which they are used. Here’s a breakdown of each:

1. Current user role is admin

Processing: Evaluated client-side unless explicitly tied to server-side logic.

Security Level: Moderate to High, depending on implementation.

If this condition is purely client-side, it is less secure because a determined user could manipulate client-side data to bypass restrictions.

If the role verification is tied to a secure server-side workflow or privacy rules, it can be secure.

Use Case: Best when combined with server-side validation, especially for critical operations requiring admin privileges.

2. Current user is logged in

Processing: Usually evaluated client-side.

Security Level: Moderate.

While checking whether a user is logged in ensures authentication, it doesn’t provide authorization. A logged-in user might not have the necessary permissions for a particular action.

Secure if combined with other conditions (e.g., role checks or database queries) evaluated server-side.

Use Case: Basic checks to ensure a user is authenticated before granting access.

3. Do a search for: count > 0

Processing: Server-side.

Security Level: High.

This condition is inherently processed server-side because it involves querying the database. As a result, the logic and data verification are handled securely on the server.

However, the security also depends on how you configure privacy rules for the data being queried. Ensure users can only access data they are authorized to see.

Use Case: Ideal for secure verification of conditions involving database records (e.g., checking if an admin record exists).

Which is more secure?

Most Secure: Do a search for: count > 0
It is inherently processed server-side, making it more secure against client-side tampering. Privacy rules add an extra layer of protection.

Next Best: Current user role is admin , when implemented with server-side workflows or checks. It ensures authorization but can be vulnerable if handled entirely client-side.

Least Secure: Current user is logged in
While useful for basic authentication, it doesn’t address authorization and can be bypassed in client-side-only implementations.

Recommendation:

For maximum security, combine these checks server-side. For example:

First, confirm Current user is logged in .

Then, verify Current user role is admin or use Do a search for: count > 0 to validate permissions.

Always ensure sensitive conditions and data processing happen server-side to avoid manipulation risks.

So it seems that @adamhholmes and @georgecollier are correct that ‘current user is logged in’ or ‘current user role is admin’ are secure when placed onto a server side action or in a event trigger that contains a server side action step in the workflow series. The attempts to explain this to me were unsuccessful as I was focusing solely on the event trigger condition rather than on the action itself, and my reliance on the manual for accurate and clear explanations, since the manual as has been pointed out implies that ‘current user is logged in’ is used to ensure server side processing of the condition.

adamhholmes:

And why does it even matter?

I am a professional Bubble developer and educator. I want to be a consummate professional and be fully capable of answering student or client questions as they relate to all things Bubble. At times I don’t know something off the top of my head I might refer to the manual for guidance. I personally do not want to provide tips, educational content or guidance to clients that is wrong or inaccurate, so for me, it is important that I understand this fully, complete with all of its potential ramifications.

So, although the issue was not 100% devoted to the costs of the conditional evaluation, since we now live in a world where WUs are a thing, I personally find it important to know the ramifications as related to WUs no matter how small the total WU cost of the conditional evaluation is, and if I didn’t know this information for my students or clients, I’d personally feel as if I was providing a disservice to them if I was unable to answer their potential questions about WU costs related to the conditional evaluation.

Also, important to know the WU implications, again no matter how small or insignificant on an individual basis, because not every client in Bubble is attempting to build an MVP and then leave Bubble. Some are going to scale with Bubble and until they reach the point of being on an enterprise plan at a cost of $3,500/month (paid annually?) then WUs will continue to be something they are paying for.

Another reason why it matters. A potential feature request to make securing our apps even more easily. We have privacy rules that can already protect most server side actions (at least Read, Update and Delete), so using conditionals to protect server side actions or data retrieval seems a bit redundant, and if it is a bit redundant it would be even more so to use the same type of condition to secure the action as what is already in place for Privacy Rules, so for me personally, the use of ‘do a search for: count>0’ is a better choice for the condition to protect the actions than ‘current user is admin’ because why not use two different ‘keys’ to unlock two different doors, instead of a single skeleton key for all doors.

Screen Shot 2024-12-24 at 1.01.41 PM1351×115 10.1 KB

So the above screen shot, if I want to protect server side actions focused on make changes to thing or delete thing, I can simply uncheck the box of ‘find this in searches’ and with that, I protect not only against the Read of the data, but also the modification and deletion of the data. However, critically this doesn’t protect against the creation of data, except via the API.

This leads me to logically assume that if I want to leverage Privacy Rules more to protect data and related actions, perhaps I could just use the data API for all create actions and not bother with the built in Bubble create a new thing workflow action step, since privacy rules can protect against the creation of data via API but not via a workflow action step.

So, potential feature request:

Make it so privacy rules can protect against the creation of data, not just the retrieval, modification or deletion.
Allow for universal conditions…an area where we can craft conditionals like ‘do a search for: count>0’ or any other conditional that somebody might choose to use, that are universally available in the app, and can be applied to the event triggers, workflow action steps via a checkbox and a dropdown to select which condition to apply. If there is this universal condition feature, we can apply it to ALL workflow event triggers and know that ALL workflow action steps are protected if they are server side, and if the workflow series the universal condition is applied to doesn’t contain any server side actions, than the conditional doesn’t cause unnecessary consumption of WUs, again, no matter how small that cost may be on an individual basis.

Hope this clears up the confusion on why something is important for me to understand and all the downstream implications of my understanding.