Why your backend workflows might be your app's biggest vulnerability

[matthieu.bouilde]

I mean, if I was a client, this would not be a very reassuring conversation if I had to choose a visual programming plateform…

Is that AS EASY on other decoupled platforms like FF/toddle/weweb coupled with Xano/ Supabase to trigger internal workflows?

Because, let’s be honest, with that information in mind, if a user can create an account in a bubble app, there is 100% chances to have potential security breaches on existing applications (that probabalbly haven’t used George’s technique)…

[georgecollier]

@matthieu.bouilde

if a user can create an account in a bubble app, there is 100% chances to have potential security breaches on existing applications (that probabalbly haven’t used George’s technique)…

Yes. It’s hard to build secure apps on Bubble right now. They’re taking some steps to improve this, but it’s something I want them to improve more.

In the meantime, I was like ‘fine I’ll do it myself’ and build the tooling that I think users need and make it widely available.

[even]

@georgecollier

. Workflows called by App Connector

Bubble has built in functionality for authenticating through api token.

When logging a user in from backend, bubble returns api token and an expires in value (seconds). This is stored to the user to identify when to run the action again. This way you can use privacy rules and conditions on current user in public workflows by unchecking “can be run without authentication” and including header Authorization: Bearer “users api token”. If token is expired or not valid bubble will not accept the authentication. This way your apps api token is never used since bubble identifies the user through its token. Or am I misunderstanding this part of the post?

[boston85719]

I was also confused why the api tokens generated in app editor under settings - api are not sufficient.

[georgecollier]

If you have a public workflow (e.g delete user) that is generally authenticated using an admin token, then by definition it is ALSO possible to authenticate just as a logged in user.

Bubble doesn’t care who you’re authenticated as, except for privacy rules. As long as you’re authenticated by an API token or by being logged in, you’re good to run the workflow. You are incorrectly assuming that this workflow can only be run with an admin token - that is the false assumption that I’m trying to help people understand more

The issue I am highlighting is as follows:

• Many people have public backend workflows
• They assume that because it requires authentication, it will be safe and only possible to call when you want them to
• That is incorrect - any public workflow, even if it requires authentication, can be called at any time by any user.

For example, if you have a public ‘send email’ workflow, that you normally authenticate using an admin API token, then it is still possible to call that workflow just by being logged in (as in this case you are authenticated) and send emails as you please.

[even]

I really appreciate the job you are doing for making people build more secure apps because this is hard to get information and it takes a long time with bubble usage to acquire this specific knowledge.

For me I am using api keys that are generated for each user by bubble to authenticate in public api calls, this way I can even for api connector or external calls know what user is making the request and set a condition on the run. For example only if current user permissions contain send emails. I use this for all bulk create and other calls that have to go through api connector because the specific user is authenticated and my admin api key is never involved.

[ZubairLK]

@georgecollier

on the workflow condition (e.g Current User’s Role is Admin

This needs to be applied to the backend workflows condition itself.

To secure a sensitive backend workflow which is supposed to be run by admin only.

Just to make sure I read this correctly. On phone and skimming…

Thanks for the lovely work. I can see another acquisition coming ;p

Thanks
Zubair

[boston85719]

@georgecollier

then it is still possible to call that workflow just by being logged in (as in this case you are authenticated) and send emails as you please.

So a user can when logged into the app, from their browser run an api call for that public backend workflow?

@georgecollier

The security issue: When authenticated, any user can call this workflow without restrictions. From Bubble’s perspective, authentication is satisfied. This means any user could potentially delete other users as long as the privacy rules allow access to those user records - which in a recruitment marketplace could be a substantial number of users.

Is this implying that a user, who is not the user in the parameter of the backend workflow can run that backend workflow because they can ‘trick’ the system into running it via an API call from the browser, or is this a potential scenario because of developer oversight when it comes to how they implement the ‘schedule backend workflow’ action within their app?

@georgecollier

Consider a ‘send-email’ workflow that accepts three parameters:

• recipientEmail
• subject
• body

Could this be resolved by not using parameters to send those values into the backend workflow and instead retrieve them from the database in the backend workflow itself on data types that have proper privacy rule configurations?

@georgecollier

Any authenticated user

Is that the same as any logged in user?

I’m really curious how a logged in user could ‘call’ or rather run these backend workflows. I don’t know how to use Postman so I don’t test api calls through there, and instead just test from another Bubble app, but if the call is initiated from a different platform than the app itself, isn’t the user not logged in and they would need to send in an API token in the header?

@georgecollier

2. External-Only Workflows or API Connector

For workflows called only from external APIs:

1. Add a text parameter (e.g., key, token, or authKey)
2. Configure the first workflow action as ‘Terminate this workflow’
3. Add a condition: 'Only when key is not <your chosen key>.
   This creates a password-protected workflow that terminates if the key is incorrect.
4. If calling the workflow from the API Connector, provide the auth key in a private parameter.

Is this basically the same as using an API Token from the editor settings area, but just not using the tokens Bubble would generate and just creating your own?

[randomanon]

You’re starting to sound like pre-meltdown @keith

[georgecollier]

@boston85719

So a user can when logged into the app, from their browser run an api call for that public backend workflow?

Exactly.

@ZubairLK

This needs to be applied to the backend workflows condition itself.

Yep, this too

@boston85719

retrieve them from the database in the backend workflow itself on data types that have proper privacy rule configurations?

Yes

@boston85719

@georgecollier

Any authenticated user

Is that the same as any logged in user?

Authenticated = logged in or admin token

@boston85719

if the call is initiated from a different platform than the app itself, isn’t the user not logged in and they would need to send in an API token in the header?

You can just attach the authentication that’s normally sent from the browser which says you’re authenticated (i.e your login cookie)

@boston85719

Is this basically the same as using an API Token from the editor settings area, but just not using the tokens Bubble would generate and just creating your own?

No.

[georgecollier]

@even

For me I am using api keys that are generated for each user by bubble to authenticate in public api calls, this way I can even for api connector or external calls know what user is making the request and set a condition on the run

The condition part is the part that is necessary to make this worthwhile. Keep in mind that these logged in users can still call the workflow whenever they want, so it’s important your conditions protect to ensure they can only run it when it makes sense to do so and they have permission to do so within the app.

The only value authenticating as a specific user has is:

1. Allowing you to use Current User in BE workflow
2. Restrict data access in BE workflow by privacy rules

It doesn’t change the problem I’m talking about in particular, which is that we don’t know if the request came from app logic, or direct manipulation.

[ZubairLK]

@georgecollier

You can just attach the authentication that’s normally sent from the browser which says you’re authenticated (i.e your login cookie)

What is the easiest way to access this?

Last time I had to make a very workaroundy self API call with a magic login in backend and return that.

I suspect there is an easier way I don’t know about…

Thanks
Zubair

[georgecollier]

Backend workflow that takes a username and password parameter and a single log the user in action that uses these parameters will return a login cookie

[ZubairLK]

Yea that’s how I had to do it…

Thanks

[georgecollier]

Yep, just keep in mind that doesn’t protect against the fundamental issue I mentioned in the post though!

[alanpieczonka]

@georgecollier Hey there, thanks for this post!

Just wanted to mention that for backend workflows using the “Detect request data” parameter definition, instead of adding extra text parameters like key, token, or authKey, one can enable the “Include headers in the detected data” option. This lets you access the Authorization header (e.g., “Bearer xxx”) directly. You can then validate it as a text as part of the initial “Terminate this workflow” step.

In the “Terminate this workflow” step, I’d also suggest embedding <your chosen key> within an Arbitrary text. This way, it’s only revealed after an additional click, rather than being displayed openly on the screen

[georgecollier]

Yes, both suggestions are correct and useful recommendations! That’s one way to verify the call came from an admin (or the Bubble app) rather than any user.

[boston85719]

@zubairk20028

For instance, a delete-user workflow should check if the caller is an admin before proceeding.

Would that be as simple as a condition on the action?

@zubairk20028

Never assume that parameters passed to a workflow are safe. Validate the inputs to ensure they conform to expected formats and values.

Could you provide an example of this?

@zubairk20028

When using admin API tokens, ensure they are scoped to specific actions and not overly permissive. This prevents unauthorized actions even if a token is compromised.

Is this basically suggesting, we could create API Tokens in the editor for each backend workflow so that only one API Token is used for one backend workflow and each backend workflow as a different API Token?

In the example above I have the create load api token used only on the backend workflow that creates load, while the Old api token is used on a different backend workflow. Is that similar to your suggestion?

@zubairk20028

Privacy Rules as a Backup

Amen to that. Privacy rules are a backup and not a first line of defense.

@alanpieczonka

Just wanted to mention that for backend workflows using the “Detect request data” parameter definition, instead of adding extra text parameters like key, token, or authKey, one can enable the “Include headers in the detected data” option. This lets you access the Authorization header (e.g., “Bearer xxx”) directly. You can then validate it as a text as part of the initial “Terminate this workflow” step.

In the “Terminate this workflow” step, I’d also suggest embedding <your chosen key> within an Arbitrary text. This way, it’s only revealed after an additional click, rather than being displayed openly on the screen

This is great addition to the conversation and really helps make the security measures even more robust. Thanks for sharing that.

[georgecollier]

@boston85719

Privacy rules are a backup and not a first line of defense.

You know that privacy rules really are the only thing protecting data access, right? If a privacy rule doesn’t restrict it, it is accessible no matter what other conditions or constraints you have anywhere.

Also, @zubairk20028 just posts ChatGPT nonsense so don’t waste your time.

An admin API token for each workflow makes no sense - if using a unique token parameter each workflow (which would be good), don’t use an admin token, just use any random string.

[boston85719]

@georgecollier

it is accessible no matter what other conditions or constraints you have anywhere.

I don’t think that is true. In a test app I have a data type of User with a field of Company, data type of Company and data type of Team with field of Company. Search is simple constraint.

When the User is logged out, no results are shown and in network tab, a search is not even performed, and there is no data accessible. If the user is logged in and has a company field populated, correct results are shown and network tab only shows their company teams returned. If the user is logged in and company field is empty, no results are shown and in network tab doesn’t perform a search at all.

So I imagine that from that simple test, a simple constraint can make it so that even without privacy rules on any of the 3 data types, it is not accessible from the client device.

Also, if I do not enable the data api on those data types, the data is not accessible.

So, could you provide an example of how a user can access the data no matter what conditions or constraints there are, while there are no privacy rules and the data type is not exposed via data api? Obviously, I’m not advocating for people to not use Privacy Rules, I’m just stating they are not necessarily the first line of defense.