Why all of your server-side redirects are insecure

@georgecollier I finally got a chance to ask ChatGPT about some of this. The tip you provided is great and the idea to implement as a best practice to secure our workflow actions is spot on. I had no idea users could alter things from their device such as the user role field.

In my goal to figure a best practice for what type of conditional to use in order to best secure our sensitive workflows, I was going toward the idea of using a server side evaluated conditional like ‘current user is logged in’ or ‘do a search for user with conditions of email is current users email and role is admin: count>0’.

Hopefully what ChatGPT purports to be a best practice guidance will be useful to others to implement a more robust and secure conditional on sensitive workflow triggers.

1. Security of Client-Side vs. Server-Side Evaluation

  • Client-Side Evaluation (e.g., current user's role is admin):
    • Vulnerable to manipulation: Since the role field is part of the current user object sent to the client, a user can modify their browser state to fake the role value (e.g., changing it to admin).
    • Not reliable for protecting sensitive workflows, as a malicious user could bypass it.
  • Server-Side Evaluation (e.g., current user is logged in):
    • Secure against tampering: This validation occurs entirely on the server, relying on a session token that a user cannot alter from their browser.
    • Ensures the user’s identity is verified and trusted before performing sensitive actions.

2. Combining Both Approaches for Robust Security

While server-side evaluation is more secure, a best practice is to combine both client-side and server-side conditions:

  • Client-Side Condition:
    • Acts as a first line of defense to prevent workflows from being triggered unnecessarily (e.g., hiding a button or preventing a user from starting an invalid workflow).
    • Example: Use current user's role is admin to hide UI elements for non-admins.
  • Server-Side Condition:
    • Acts as the final authority to validate sensitive actions before they execute.
    • Example: Use server-side workflows or checks to confirm that the current user has the correct role and permissions (e.g., Search for User where ID = current user’s unique ID and role = admin).

3. Why current user is logged in is More Secure

  • Server Dependency:
    • The current user is logged in condition depends on the session token validated by the server. This ensures the user’s session is legitimate and not manipulated.
  • Cannot Be Faked:
    • Unlike current user's role is admin, which could be spoofed client-side, the server independently validates the user’s login status.

4. Best Practice Recommendation

For securing workflows:

  1. Always include server-side validation for sensitive actions, such as:
  • Validating the user’s role or permissions via a database query or backend workflow.
  • Example: Use a server-side check like Do a search for User where ID = current user’s unique ID and role = admin before executing the workflow.
  1. Use client-side conditions as an additional layer for efficiency and user experience, but never rely on them for security-critical actions.

For me, based on ChatGPT input on this, I think I’ll be using the 'do a search for user with constraints email is current user email and role is admin: count>0'

I’m going with this conditional as I believe that the users email field can not be overwritten since it is a built in field that is basically the mirror of unique ID, although we can alter it with what I assume are server side actions of change user credentials.

@georgecollier Do you know if a bad actor can modify client side the current user email field? I personally have no idea how to do this myself to test it.

1 Like

I was wondering would running the condition “Current User is Admin” on a “Page is Loaded” event be safe?

I’m assuming that Current User data is always loaded (at each refresh) first before the event runs. Since the Current User data is always called during a refresh (again I am assuming), there’s hardly any opportunity for a bad actor to modify Current User values.

It depends for what. I’ll get back to Matthew’s post later once I can test some more, but if you’re trying to redirect a user, that won’t work because it can be bypassed.

If you’re looking to run an event, my current understanding is that client side actions in the workflow may run, but server side actions like modifying/creating Things will return an error.

In this realm, it’s as easy to edit values in 0.001 seconds as it is to edit in 10 seconds :slight_smile:

1 Like

Does the security scanner work when an app is on a subdomain? I just went to scan mine and it said ‘not a bubble app’. (I did provide the subdomain url.)

Make sure the link you provide doesn’t have a redirect! e.g if your index page redirects to /login, then provide app.yourdomain.com/login :slight_smile: I’ll take a look for you!

Edit: Looks like the link you provided was not a Bubble app (as you only have the Bubble app on specific page paths, probably using Coalias). We handle redirects effectively, but your homepage didn’t redirect to your Bubble app so it logically couldn’t find it!

1 Like

Wow this is some good info @georgecollier !

1 Like