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

[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.