If I have a single top-level element that holds my entire page (invisible by default), there’s no security difference between showing it with a workflow vs condition, right? Someone could access it either way?
Can you secure a workflow via a server side checked condition ? Does a conditional on an element controlling visibility get checked server side?
Well, the data required to evaluate the condition can be downloaded from the server, but the evaluation is client side.
All elements a page has (incl. reuseables) can be forced visible by a technical user. Element visibility is not part of Bubble’s security model.
The only way to stop users doing ‘stuff’ are server side conditionals on workflow event (or appropriate conditions inside the workflow / permission check custom event etc).
If a page has a server side redirect for User P, then P will not be able to run workflows on that page even if they have no conditions (useful for admin pages etc).
1 Like
Say you have a page is loaded event –> Show Element
The condition on the event is checked serverside. Still doesn’t matter because Show Element is clientside?
Interesting, didn’t know this. Would this include workflows that show elements (like the one described above)?
It doesn’t matter, because the code for the hidden elements is downloaded for invisible elements on page load. The client has all the info it needs.
You implicitly know this because when monitoring network requests, the only ones you’ll see after page load are database queries, some data API calls and workflows. If a user gains access to an invisible part of the page, you don’t see more stuff getting downloaded to display it.
Test yourself. If an action, has a condition that is checked server side it will not run, that includes a client side action.
The security comes from the conditional evaluation and where that takes place. Think as you seem to know for a go to page action…if the condition is checked server side versus client side check, there is a major security implication difference. A go to page action is a client side action same as a show element action. The key is where does the condition to run the action take place, is it checked server side or client side.
That’s why I posed the questions to you, so you’d ask the correct question and get to correct answer.
A condition will ONLY be checked on the server if it’s a server action.
For client side actions, the condition is checked on the client (obvious when you think about it).
A ‘Go to page’ is a Client-Side action.
So any conditions for that are always checked on the client.
Yeah, Go to page is literally just ‘navigate browser to a URL’. There’s zero security difference where a condition is placed or how it’s structured, because outside of the workflow I can just… you know… go to the page
So I’m not sure what you mean by this part (at least in the context of a Go to page action):
Any client side action can be run arbitrarily at any time by any technical user, irrespective of workflows or how it’s used. That’s because a client side action is literally ‘run some javascript in the browser’.
I guess I’m misinterpreting this part of the manual
I thought it read that if its applied to the workflow it prevents all actions within that workflow from being executed, and I imagined that there are certain conditions that are always checked server side.
So, for me, I had the thought that if I had a condition that was Do a Search for User with constraint of unique ID is equal to current user unique ID that it would be checked on the server only, and not on the client device. I guess that is not the case for a client side action?
Another area of the manual I may be misreading below
I understand that it uses the example of current user admin=yes, which I suppose could be manipulated client side, but the general gist I took away was any server side checked conditional is checked server side regardless of what type of action, either a client side or server side action, since it is the condition that matters where it is checked and not the type of action it is checking a condition for…maybe the manual has a bad example of current users admin = yes, since it could be manipulated client side?
Perhaps maybe if the privacy rules just kept the admin field not visible to anybody, it would cause it to be checked on server?
@adamhholmes @georgecollier do you know which types of conditions are checked server side? The manual seems to state in a few places there are some types of conditions that get checked server side…I think the most likely is the Do a Search for since, searches happen on the server. I’m not sure though as stated…
it is, but I took from the manual it is not the action type that matters and instead the condition that matters.
yeah, but wouldn’t it matter if the condition fails and so the action doesn’t run…like if I have a condition that is Do a Search and it returns No, doesn’t that cause the action to not run?
Is that to imply I can write my own javascript to create my own workflow action in the dev console, or to say that you can write the javascript to trigger the existing workflow event so as to run the workflow events, even if those events have a condition on them?
It won’t run, but if it’s on a client side action, it can technically be bypassed. And that’s ok, because nothing important happens in the client.
I mean in theory yeah, but what I meant was you can run any client side action, because all client side actions are is ‘run javascript X’, which you can obviously simulate yourself outside of a workflow. Display data in group X is ‘run javascript to set group datasource property to (unique ID)’.
2 Likes
It really has nothing to do with the ‘type’ of condition.
More or less ANY type of condition can be checked on either the server OR the client, if the required data is available where it’s needed.
Rather, it’s entirely to do with WHERE the condition is checked - which is entirely down to the type of action (and also where the data being used comes from).
i.e. for a server action (like making changes to a Thing) with a condition Only when Current User’s Admin is yes it will be evaluated on the Sever before the action runs (using the data on the server).
The exact same condition on a client-side action (such as Show Popup or Set Custom State) will be checked on the client (using the client-side data).
If the condition is put on the WF Event itself, then any server actions within it will have the condition checked on the server, and any client-side actions within it will have the condition checked on the client. On the server, the condition is checked directly against the data from the database, whereas on the client-side the condition is checked against the response that exists in the browser.
Conditions only get checked on the server if the action happens on the sever.
It’s irrelevant that a search is done on the server, as the response is sent to the client - and it’s the response that is used (obviously) in evaluating conditions on client-side actions. And the response can very easily be manipulated.
I think the confusion arises from the very nature of Bubble…
One of Bubble’s main strengths is its seamless integration between front and backends - where it really blurs the lines between the two concepts.
A consequence of that, however, is that it can lead to confusion about what happens where.
If you were using (for example) Xano and WeWeb, any such confusion would be almost impossible.
You’ve got it exactly backwards - it’s the type of Action that matters, not the type of condition.
Although, there is more to it that that..
If the Data used in the Condition is directly accessible to the Server (which means, primarily, Data from the DB, or maybe some other API call) then, when checking that condition on the server, there is no ability for manipulation.
Whereas, when checking a condition on a server action, if the data being used came from the client (such as a custom state, or group variable etc) then, obviously, that data could be manipulated (this has some important, and often overlooked consequences).
I think that is what the Bubble manual is getting at.
If the Admin field is not available then it won’t be accessible for evaluation in conditions at all (it will always be No) - except in BE WFs with Ignore Privacy Rules.
2 Likes
Yup, ‘frontend workflow’ (as we generally call them, to differentiate from backend workflow) is a misnomer and definitely confuses things.
1 Like
Exactly… most ‘front-end’ WFs are a mixture of client-side and server actions (or, more precisely, requests to the server to perform server actions).
And neither the Bubble Editor nor (with the exception, kind of, of the WU section) the Bubble Manual make any obvious distinction between the two.
Which, I suppose, is either a good thing or a bad thing, depending on your viewpoint.
But it does catch a lot of people out, especially those with less knowledge of more standard dev processes (which is probably most people, at least when they first start out using Bubble).
I’ve often thought it might actually be more helpful to everyone in the long run if that wasn’t the case (i.e if there was some clear and obvious distinction in the WF editor between actions that are client-side and server side).
But i guess it’s never really as clear-cut as that in Bubble…
e.g. a single ‘Set Custom State’ action which uses a Database item as its value might be a combination of several server requests (searches) and the client-side action of actually setting the state, so it wouldn’t really fit in either category.
Okay, so combining these two statements has me confused
What I’m reading there is if the condition is checked on the server, there is no ability to manipulate the check…wouldn’t that imply no ability to manipulate the result of that check?
What I am reading is that it doesn’t matter that the server performed the conditionally check and sent a ‘negative’ result back to the client for whether or not a client side action can run, that can be manipulated…this part I would wonder, how is that manipulated client side, is the result intercepted somehow to manipulate it client side before the client side action understands not to run…because @georgecollier said this…
Does the technically be bypassed part mean the same thing as the response can very easily be manipulated so that a condition checked on the server will be ‘intercepted’ and manipulated before the client side action fails to run?
So, I think in practice this is not possible…at least in the context of the discussion for making an element that is not visible, to be shown, via an action with a condition that is checked on the server. The reason I believe this is that when we have an element that is set to not be visible on page load, on page load, it is not in the DOM, and so the element is not known, nor can the internal config or editor be inspected client side to find the not visible element or it’s ID…so it technically wouldn’t be possible for a user to run a javascript X to show an element whose ID they do not know, nor could find, as it doesn’t exist in the DOM.
I think I’m on the same page of understanding here, that security comes from if a condition is checked on the server or on the client, and often enough, that comes to whether the data is already on the client or if it is on the server.
So, now, my only confusion comes down to, whether or not in practice, it really is possible for a malicious user, to intercept the result of the server side conditional check.
If it is possible that a server side checked condition result can be intercepted and manipulated client side before the client side action that requires the condition to be met having failed to run if the result is negative, wouldn’t that be true of a custom event that handles conditional evaluations like in @georgecollier better boilerplate, where the check is a server side check but result is returned and passed through to other workflow series to terminate a flow if the check is negative?
I’d imagine that if there is enough ‘latency’ for a server side conditional evaluation result to be intercepted and manipulated before received by the client side action it is a condition of, and so becomes not secure to stop the client side action of show element from running, that a custom trigger returning data has more latency and would also be not secured?
By the way the only reason I asked this question was because there’s a difference in API calls being used as elements (data) vs workflow actions (actions). You can tamper with the former but not the latter. But then I realized that the only reason this is true is because the API call is still being made from Bubble’s servers.
Ok here’s the misunderstanding
Bubble doesn’t send back to the client a ‘yes/no’. It sends the data required for the client to evaluate that. Then the client decides what to do.
This is tangentially related, but a client side action is something that happens on your browser. By definition you can manipulate the response from Bubble to be whatever you want.
Give me a test page (content shown via workflow action or something) and I’ll show myself forcing that ‘hidden’ thing to be visible to reveal its contents if you want
1 Like
I think you realised already but the reason it’s a custom event rather than workflow condition is just for maintainability (basically a reusable expression). But it serves the same purpose.
Here’s what happens step by step for the workflow above:
- When input’s value is changed, API call (/workflow/start) is sent to Bubble. It includes my user ID, and the input’s new value.
- On Bubble’s server, the custom event is run. It evaluates the condition in return data
- Bubble terminates the workflow based on that
- That result is returned to the client
- Client knows not to continue with step 4 (show toast), but I could sit in the middle and ‘fool’ the client into thinking Bubble let the workflow continue, so it returns step 4. However, that wouldn’t change the fact that step 3 didn’t run, so there’s no security issue.
1 Like
Correct (on the server).
It’s simple (in most cases) to simply change the data on the client-side and use that modified data instead of the real data. i.e. If the Current User’s isAdmin is ‘No’, it’s very simple to change that to isAdmin is ‘Yes’. That’s what I meant by ‘very easily manipulated’.
Maybe.. but there are other ways to ‘bypass’ conditions as well, - for example just removing the condition from the executed code completely, or changing the required values in the condition itself. Or just running the action, or making the element visible directly etc.
There is no such thing as an ‘action for making an element that is not visible, to be shown, via an action with a condition that is checked on the server.’
That cannot exist.
An element exists only on the page. Therefore ANY condition used to show or hide it can ONLY be checked on the client.
Just because it’s not in the DOM does NOT mean it hasn’t been sent to the client in the page code.
The DOM is only what is currently instantiated and rendered on the page.
All the code needed to render ALL elements on your page, including those not visible on pageload, is sent to the client when the page loads.
As @georgecollier pointed out already, it’s easy to confirm this by checking the Network tab of the browser tools when the previously hidden element becomes visible…
NO new network requests are made, so everything needed to render the hidden elements is already there.
Server-side conditional checks ONLY happen with server-side Actions (so, no - within reason, server-side condition checks cannot be intercepted or manipulated).
Again.. there is no such thing as a ‘server-side conditional check on a client-side action’.
Conditions for Client-side actions happen on the client.
They may, or may not, use data that was requested from the server, but it’s on the client that the condition is checked, and the data used in the check is the data that exists on the client, and that can always be edited.
Exactly this…
Searches don’t return Booleans, they return lists of data (or single data items, or numbers in the case of Agg searches).
Conditions check data, that may or may not involve a search, and then evaluate whether to run the action or not (or display the element etc), based on whatever data it has.
1 Like
I mean, easier to show rather than tell
Here’s me forcing every element on Bubble’s projects page to be visible (I closed a few popups so its easier to see)…
1 Like
POV: you’re a boomer browsing the internet on your virus-laden windows desktop
1 Like