I’m a little confused about that option to run a backend without authentication. When and why would you choose that? Seems that it’s a security risk doesn’t it?
And also why would you expose as a public API?
Expose as public API makes it an endpoint for other apps to send data to your app. So like in Postmark when there’s an inbound email you can set it up to send the email data to your app.
The “without authentication” option is for when an incoming external request needs to be authenticated a different way than the usual bearer token in the header. Or it truly is just a public endpoint that requires no authentication
For example if request comes in from a known IP address, then you check the box “without authentication” but then add a condition on the workflow check for the IP address in the header.
1 Like
A limited risk.
‘With authentication’ just means ‘with an API token or whilst logged in’. Therefore, if a backend workflow requires authentication, and is public, it can still be called by any logged in user very very easily. It will obey the privacy rules of the logged in user, or ignore privacy rules if an admin token is used.
The real problem is when you ignore ignore privacy rules. Ignoring authentication alone isn’t ( in most cases ) much of a problem, unless you’re ignoring privacy rules too.
In the context of Stripe, it’s fine, as you can verify the integrity of the request from within the workflow. Even if a workflow is unauthenticated, you can still make it secure within the workflow itself.
1 Like
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.
1 Like
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?
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.
1 Like
I’ve got my privacy rules mostly set up since your audit lol, I lost some sleep after that
1 Like
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 
2 Likes
wow…how do they even get gold status!
3 Likes
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.
1 Like
…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.
???
Privacy rules are there so that you entire database isn’t literally exposed to the entire internet.
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.
1 Like
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.
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.”
1 Like
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.
I said a lot more than that. And what you listed isn’t even technically a security risk.
1 Like
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.
1 Like
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.
Yep, that’s called a straw man. Already called it out.
1 Like
@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’.
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.
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.
1 Like