Backend workflows: In what situations do you allow to run without authentication?

lindsay_knowcode · 2024-10-21T08:54:02.309Z

You are able to view the HTTP headers in the webhook - so can inspect and verify for example an authorization token, the referer, IP’s etc. I’d suggest, at least log some of this info so if anomalous stuff is happening you have a way of detecting and diagnosing it.

ramzizi · 2024-10-21T17:09:50.960Z

Oh man I had a few backends exposed as public, and ignored privacy rules. So dangerous.

I’m currently working on updating my privacy rules. In the meantime, Is it still terribly unsafe to have a few backends that ignore privacy rules, but they’re not public and they require authentication?

georgecollier · 2024-10-21T17:19:46.129Z

If there is a way for anyone to schedule API workflows on a non-public backend workflow, I haven’t found it yet, but I wouldn’t count that possibility out.

That said, given you haven’t got privacy rules yet, there are bigger fish to fry.

ramzizi · 2024-10-21T17:22:17.077Z

I’ve got my privacy rules mostly set up since your audit lol, I lost some sleep after that

georgecollier · 2024-10-21T17:28:03.012Z

Don’t worry, you could have no privacy rules at all and your app would have the same security as those of some Gold tier agencies

ramzizi · 2024-10-21T17:34:07.980Z

wow…how do they even get gold status!

randomanon · 2024-10-22T03:17:00.468Z

Ignoring Privacy Rules on a backend workflow that is internal and requires authentication has no inherent security risks. The biggest risk is actually accidentally modifying fields that you didn’t intend to due to errors in your search/condition logic. The Bubble Manual discusses a few situations where this is actually necessary. There are situations where you have fields protected by privacy rules that need to be checked without revealing the results or logic to the front end, that’s when you use this.

The results of the search are never exposed to the front end unless you go out of your way to expose it to the front end. For example, let’s say you need to check a field protected by strong privacy rules, you might have a search running in the backend that returns 0 or 1 (invalid/valid) without exposing the actual results of the search. In this case you keep the data protected and still accomplish the workflow.

“Ignore Privacy Rules” just means “temporarily let only the actions in this workflow see all data,” it doesn’t mean anything beyond that.

georgecollier · 2024-10-22T09:11:32.626Z

randomanon:

Ignoring Privacy Rules on a backend workflow that is internal and requires authentication has no inherent security risks

…assuming you configure everything correctly, which no developer can do all of the time. Privacy rules are there to protect you so that data is secure even if you muck up a search expression.

Ignoring privacy rules can make it easy for a user to read/update/delete something they shouldn’t.

randomanon · 2024-10-22T11:06:24.226Z

georgecollier:

which no developer can do all of the time

???

georgecollier:

Privacy rules are there to protect you so that data is secure even if you muck up a search expression.

Privacy rules are there so that you entire database isn’t literally exposed to the entire internet.

georgecollier:

Ignoring privacy rules can make it easy for a user to read/update/delete something they shouldn’t.

That user being yourself. Backend workflows are black boxes, you can trigger a workflow (assuming you meet the conditions) but after that you can’t see inside of it or modify it in any way.

Ignoring Privacy Rules is not only recommended in certain cases, but absolutely necessary:

Protecting data with privacy rules | Bubble Docs

This lets you run workflows that perform an important task with full access to data, without compromising your security by opening up the access for the current user. The operation is performed purely server-side, meaning that your users cannot see it or even know that it’s running.

georgecollier · 2024-10-22T11:30:41.654Z

randomanon:

That user being yourself. Backend workflows are black boxes, you can trigger a workflow (assuming you meet the conditions) but after that you can’t see inside of it or modify it in any way.

Take a workflow ‘deletecompany’. When scheduled by the company admin, it deletes the company. It does this by searching for the relevant data types (users, invoices, files, etc), and deleting them on a list of things.

I have accidentally misconfigured one search constraint. As such, it finds more than the company’s data.

Because I have privacy rules, that data is protected and won’t be deleted, because as far as the workflow is concerned, it doesn’t exist.

If I ignored privacy rules, that kind of error would have serious consequences as it would delete other user’s data.

I never did say that ignoring privacy rules should never be used. Just that the statement ‘ignoring Privacy Rules on a backend workflow that is internal and requires authentication has no inherent security risks’ isn’t quite right.

randomanon · 2024-10-22T11:47:47.850Z

georgecollier:

Take a workflow ‘deletecompany’.

Stopped reading there. This is a straw man. I already listed examples where you are required to use Ignore Privacy Rules. This is like arguing that walking is dangerous for your health by starting with, “Take an F1 racetrack.”

georgecollier · 2024-10-22T11:54:47.763Z

randomanon:

Ignoring Privacy Rules on a backend workflow that is internal and requires authentication has no inherent security risks.

You said this, which I didn’t agree with, so I provided reasonable a counter-example to explain why I think you’re not quite right… it does have security risks, which can be appropriately managed where necessary.

randomanon · 2024-10-22T11:55:06.102Z

I said a lot more than that. And what you listed isn’t even technically a security risk.

boston85719 · 2024-10-22T12:01:56.957Z

This is true. No security risk but there is a risk a developer goof’s up, which can happen with privacy rules themselves and how they are configured. Not using a valuable feature for fear of messing up other parts of the function is no reason not to use the valuable feature, but more just highlights the importance of checking our work before deploying live.

I use ignore privacy rules in backend all the time for things that a user should not see but does need to interact with.

georgecollier · 2024-10-22T12:20:55.213Z

boston85719:

No security risk but there is a risk a developer goof’s up

For me, being able to delete other people’s data as a result of my own mistake would be a security risk Acknowledging that at some point I’ll make mistakes, it makes sense to build in a way that protects the app from those mistakes wherever possible. Never said to never use ‘ignore privacy rules’, just that blindly enabling it on workflows where it isn’t necessary because of an assumption that it ‘has no inherent security risk’ can create security risks.

randomanon · 2024-10-22T12:53:06.514Z

georgecollier:

just that blindly enabling it on workflows where it isn’t necessary

Yep, that’s called a straw man. Already called it out.

Straw man - Wikipedia

boston85719 · 2024-10-23T10:10:08.596Z

georgecollier:

Never said to never use ‘ignore privacy rules’, just that blindly enabling it on workflows where it isn’t necessary because of an assumption that it ‘has no inherent security risk’ can create security risks.

randomanon:

Ignoring Privacy Rules on a backend workflow that is internal and requires authentication has no inherent security risks. The biggest risk is actually accidentally modifying fields that you didn’t intend to due to errors in your search/condition logic.

georgecollier:

…assuming you configure everything correctly, which no developer can do all of the time. Privacy rules are there to protect you so that data is secure even if you muck up a search expression.

Ignoring privacy rules can make it easy for a user to read/update/delete something they shouldn’t.

@randomanon provided to me what was the best example of a situation to ignore privacy rules. I didn’t read the part that you mentioned doing so ‘just blindly’ or where @randomanon said to do so ‘just blindly’.

georgecollier:

Because I have privacy rules, that data is protected and won’t be deleted, because as far as the workflow is concerned, it doesn’t exist.

Just having privacy rules in place does not mean that the developer has set up the privacy rules correctly, as developers can make mistakes with the privacy rules themselves. I know in my time, I’ve made mistakes with privacy rules that make data not available when it should be.

Everybody is capable of making mistakes while building, and those mistakes can be in any area. One of the biggest mistakes we could make is deploying to live prior to robust testing in development to uncover any mistakes we may have made.

But either way, @ramzizi what you can take away from this is that @randomanon example of a situation to run without authentication (ie: ignore privacy rules) is one of the best example for ignore privacy rules, but @georgecollier and @tylerboodman gave great examples of how to use the ‘run without authentication’ as the two (ignore privacy rules vs. run without authentication) are different from each other and would be use for different scenarios.

georgecollier:

Take a workflow ‘deletecompany’. When scheduled by the company admin, it deletes the company. It does this by searching for the relevant data types (users, invoices, files, etc), and deleting them on a list of things.

I have accidentally misconfigured one search constraint. As such, it finds more than the company’s data.

Because I have privacy rules, that data is protected and won’t be deleted, because as far as the workflow is concerned, it doesn’t exist.

If I ignored privacy rules, that kind of error would have serious consequences as it would delete other user’s data.

This would be an example of needing to appropriately configure the database structure as well as the order of operations. If the other related data, such as users, invoices, files etc. all had a field that is related to company, and the backend workflows were structured in an order of operations so as to not have a potential issue, which would be, the first step is not to delete the company, but rather to start deleting the related data, such as users, invoices etc. based on a parameter that is sent to the backend workflow being ‘company’…only after deleting all related data, the last step is to delete the company itself. This is important as there is the possibility that Bubble makes another change in the future that makes it again a situation in which when we have a related field and the data entry of that related field is deleted, the entry is removed automatically. In the past Bubble did this, meaning that on a invoice, the company data field would be empty as soon as the company data entry is deleted. Bubble does not do this any longer as far as I can tell since I am able to see the UID of the company in the invoice data entry field for company, but we never really know what they may do in the future to change this again. Hopefully they would change this back to the way it was previously as having a data field ‘not empty’ despite it’s related data entry being deleted is bothersome.

Additionally, the use if ‘ignore privacy rules’ should be used in this example in my opinion, since the User data type should have privacy rules on it, and the schedule of backend workflow to send in the parameter of company should be set to ‘current users company’ and when in the backend, the current user may not be recognized if not logged in when the backend workflow runs, so having the ignore privacy rules on the schedule of backend workflow action as well as on the backend workflow trigger itself, to ensure the correct company is sent to the backend workflow as a parameter and all of the correct related data entries are found based on the parameter of ‘company’.

Privacy rules should be considered more of a feature to ensure the data is not publicly available on the internet when it should not be, rather than a stop gap approach to mitigating potential errors during development. For me personally, I believe a best practice when building is to implement privacy rules last. This means, building the platform, testing everything works right, then implementing privacy rules and then testing for them. This is based on years of experience that I make mistakes when testing and do not always log in, so I end up spending time trying to debug something that is only an issue due to privacy rules and not being logged in, and the debugger and logs do not always show that privacy rules are conflicting with the availability of data.

randomanon · 2024-10-23T16:03:54.752Z

boston85719:

Additionally, the use if ‘ignore privacy rules’ should be used in this example in my opinion, since the User data type should have privacy rules on it, and the schedule of backend workflow to send in the parameter of company should be set to ‘current users company’ and when in the backend, the current user may not be recognized if not logged in when the backend workflow runs, so having the ignore privacy rules on the schedule of backend workflow action as well as on the backend workflow trigger itself, to ensure the correct company is sent to the backend workflow as a parameter and all of the correct related data entries are found based on the parameter of ‘company’.

This is a good point. If a backend workflow schedules itself with the current user as a parameter, the second one would be ran by “the system,” right? Meaning it wouldn’t recognize it as Thing’s Creator.

boston85719 · 2024-10-23T16:46:19.182Z

randomanon:

If a backend workflow schedules itself with the current user as a parameter, the second one would be ran by “the system,” right? Meaning it wouldn’t recognize it as Thing’s Creator.

I’m not 100% sure, but it is likely, since the user is not the one to schedule that second backend workflow and instead would be ‘the system’, although, Bubble may have smartly made it work in such a way as to recognize that the first schedule workflow was done by a user, so maybe they made it that any other backend workflows schedule in the chain would inherit the user, but I don’t know for sure.

Definitely is the case with webhooks though. I generally try to do the same type of thing regardless of the situation, which would mean, that if I need to do it a certain way for chains of backend workflows initiated by webhooks to function properly, I’ll use the same approach for the chains of backend workflows initiated by the user…but of course there are going to be times when there are needs to alter an approach.

As an example of webhooks, when I work with Stripe, I often need to search for a User based on an incoming webhook, so something like subscription id or customer id, which are under privacy rules, but I need to access the user data type in webhook backend action to then schedule other backend workflows in the chain. Or if working with a system that connects Zoom with Google Calendars. The google calendars details are hidden by privacy rules, but the webhook from zoom requires me to search for the User to get their google calendar details to add the event they have been invited to via zoom. When zoom webhook is received in the app, I need to ignore privacy rules in order to find the user.

randomanon · 2024-10-24T09:22:03.946Z

OK, so I actually created a test workflow and discovered the following:

You don’t have to pass the User as a parameter, and you don’t need to ignore authentication or ignore privacy rules, the “Current user” authentication is passed along as long as the original trigger is from a logged in Current User. It also obeys any conditions related to the Current User (e.g., Current User’s Role is ___).

This actually is better than using a “user” parameter since theoretically if you’re passing this from the client they can input whatever user they want.

You can see this in the scheduler itself:

I also confirmed that “Current user is logged in” succeeds as a condition, even if you’re logged out, assuming again that you triggered the initial workflow while logged in. It just keeps carrying over.