Stripe Webhook in Bubble - big vulnerability to all apps that use them


i found a important vulnerability of every app on bubble that use Stripe webhooks.
As one of the feature, bubble offer a Swagger file with all the endpoint and the relative object publicly on the internet.

That + a endpoint setup to receive information from stripe about payment will give the opportunity to everyone to send spam information to bubble and maybe confirm payment that are not been done.

To avoid this stripe provide a “Signature” to check the webhook content is from stripe or not, and if there was a M ITM .

I send a mail to bubble support, with my concern and they suggest me to check with you (the community) what to do.

i’m sorry if my English is not the best, i hope that everyone can understand, and we can find a way to fix this issue.


wait, what? you found a security vulnerability in the official bubble stripe plug in affecting all apps using the much touted bubble stripe integration… and they referred you to the forum for a solution?

@casheets123 This is not related to official Bubble Stripe Plugin
Using your own custom webhook mean that you have created your own integration


right. that makes more sense. thanks.

if this is related to this funnily named “swagger” file that bubble provides. should this be of more concern and some type of official warning from Bubble be in order to not use webhooks with stripe until resolved?

or this has nothing to do with Bubble per se?

For me there’s 3 ways I can see right now:
A) Create something that will validate signature. It can be done probably using Toolbox or create a plugin
B) Use metadata. A little bit like “state” that you can pass with an authorize url that is returned by the app, you can send a metadata that will be provided back in the webhook. Don’t forget that there’s a lot of thing too guess that you can validate when data is back (amount, ID… )
C) Don’t use webhook! … instead use a recurring workflow that will check for payment status. This really depend of your usecase.


That’s exact but, this is very commune when you use Stripe in your App to use Webhooks to check on payment, subscription or other events.

This mean that setup like this:

will make your app vulnerable to spam and fake record on your database.

1 Like

@matt_moo You’re saying Stripe offers a swagger file with publicly available endpoints, can you show it to us and the content of it? I hardly doubt they will expose customer_id’s publicly.

All of my Stripe webhooks do a search for a customer id based on the webhook response. Good luck to any hacker guessing my client’s id?

I might have understood this the wrong way, so please correct me if I’m mistaken.

Bubble offer a swagger publicly available, not Stripe, but Stripe have their documentation, so it’s the same :stuck_out_tongue:
But we are talking about Bubble Webhook that can be “hacked” if not enough security are implemented.

I will add a 4th way:
D) When you receive the webhook, do a Get request to Stripe API to validate the status of the payment.


is what i’m doing for checkouts, but having multiple subscription, i need to update my database with payment status of all the subscription and this is when you need webhooks.

Webhooks are one of the basic and more popular way to setup event driven apps.
With out webhooks, there is no way you not reach the API limit of stripe with a normal/medium customers base (100 write operations per second), if you ask a list of invoice is 1 operation for invoice, if you request a invoice details is 1 operation for every entry.

this the only way for now, but it use resources, and API operations for something that normally is done by the backend.

1 Like

I don’t have spoken on haking, my post is more oriented to warning you that you can be easly spam, or if you dont use checks event fraud.

Here is a the documentation on swagger: Defining the API - Bubble Manual

Some business to protect them self even better, they use custom endpoint that dont make sense (we use UUID in the past) so is really hard to discover where the webhook is located, but this is useless on bubble because swagger file is public (btw i use it al lot and i like that is public, but is something that you need to consider).

If I understand this issue correctly, couldn’t an API token be used in the URL as described in the reference? I realize it’s not as secure as using it in the header and that it says nothing about the integrity of the payload, but surely it’s better than nothing, no?

Hello @sudsy

if you use RestAPI yes you can use API, there is no signature check there needed, stripe use DNSsec so risk for MITM is super low.

But webhooks are just endpoint that you expose on your bubble app, and with out signature you can’t be shore is the call come from stripe or from a bad guy that just want to let your app think that he have pay his bill.

a cool feature for bubble is the auto swagger file generation, swagger file is a open standard that let you document all the expose endpoint in your app, in this case a bubble app.

Let’s take an example that you have a store and you have setup the stripe hosted checkout, or a stripe element checkout, and you will send your order automatically every time you have a successful payment.

As a bad guy i can just look at your swagger file, generate a checkout session in stripe using your store, with our closing the tab i can sent to your software a call on the endpoint providing fake info. and that’s it.

I have trick your bubble app. to think that i have pay my checkout.

I’m not sure we’re on the same wavelength. I’m talking about using Bubble authentication on the endpoint. If the “bad guy” doesn’t know the secret API token, how would they “get past” the endpoint?

you can’t use that with stripe.

Why not?

Because stripe webhooks use signature, not http auth or other type of auth.

I’m sorry, but I still don’t understand why a developer couldn’t simply add the Bubble auth token as a query string parameter to the end of the URL when the webhook endpoint is added in Stripe. I’ve done it with non-Bubble integrations in the past with no problem. Stripe will hit your endpoint with the URL as it was entered in the Stripe dashboard.

you don’t want to put a “root-like” token in stripe, especially because is not encrypted.

You will save it on the webhook url in stripe, and then all the obj endpoint are exposed too if that token get discovered.

I didn’t say it was bulletproof. I said it was better than nothing at all, which is apparently the case with some Bubble integrations now, right?

if you want to precede that way you should create a custom check and not use the ROOT apikey.

But if you are in EU, CH or other GDPR regulated country you can’t do that.
Direct access to private customer content can’t be given to external entity.