@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 therole
value (e.g., changing it toadmin
). - Not reliable for protecting sensitive workflows, as a malicious user could bypass it.
- Vulnerable to manipulation: Since the role field is part of the
- 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.
- The
- 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.
- Unlike
4. Best Practice Recommendation
For securing workflows:
- 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.
- 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.