🎉 Better Boilerplate by Not Quite Unicorns - Our take on what a good Bubble app looks like

[georgecollier]

@branimir.ivanov

i just tested it - simply making POST requests to webhook endpoint /stripe-subscription, WF creates new database entries (Subscription data type) every time, even without valid stripe data.

Ah, it’s because this workflow was missing a terminate action like all of the other ones Still, whilst you could create empty rows, that’s not particularly useful! The design of the endpoint means that if mistakes do happen that let a user through that shouldn’t be, they still can’t do any real damage.

Everything we build in Bubble should be built in a way such that there’s no single point of failure (and you found one example of why there’s multiple protections)

@branimir.ivanov

when using api tokens, the workflow only runs when authorized, which prevents unauthorized workflow runs and database writes.

No, that’s not true.

Take this workflow (I just edited it for demo) as an example:

This would not be secure.

It seems to me that you think that it is secure because it requires an admin token. That is not true. It requires to be authenticated, and any user with an account in this case can be authenticated. So, all it does is restrict the endpoint to subscriptions the user’s privacy rules permit them to access (their own subscriptions).

Edit: You might find this post useful!

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

Understanding and Securing Public Backend Workflows in Bubble The Common Misconception After misconfigured privacy rules, public backend workflows represent the second most prevalent security issue in live Bubble applications based on what I’ve seen from auditing dozens of apps. There’s a widespread misunderstanding about their security model that you may not be aware of. Many developers assume that requiring authentication is sufficient to secure a workflow. However, this assumption is incorre…