As I’m building out my public site, I am constantly thinking about how bots can rip through all my WUs by submitting public forms over and over again, or loading pages that get data from the DB constantly.
I’m putting heavy WU processes behind authentication and authorization gates, but I fear it’s not enough. My site will be behind Cloudflare, but it can’t stop all robots from doing robot things.
Does any know if Bubble has any built in protections from bot abuse, and do you have any tips to prevent malicious users from burning through a site’s WUs?
Well, for your forms, obviously you can use CAPTCHA. And you can do that without a plugin.
You can also set up your own Cloudflare account if you have a custom domain.
Bubble uses it but if you want more protection you can also create an account.
With your own account, you can turn on bot fight mode, firewall rules, and rate limiting.
It sounds like you’re already using the need to log in to access certain things that would create a lot of WUs.
Added: Bubble also lets you decide if you want to keep your WUs from going over…which is also a built-in feature. You could look into that feature as well.
Sadly, Bubble does not support using your own Cloudflare account in Proxy mode, so all of the protections that a Cloudflare WAF, cache, bot fight mode, etc can offer you are not available to Bubble customers.
Bubble should offer customers a choice:
Use Bubble’s Enterprise Cloudflare account, or
BYOC - Bring your own Cloudflare
There’s also this feature called Orange to Orange for SaaS providers:
According to ChatGPT:
If Bubble were to integrate Cloudflare for SaaS on their backend—onboarding each customer’s custom hostname into Bubble’s Cloudflare zone via the Cloudflare for Platforms APIs—then their customers could simply create a CNAME record in their Cloudflare DNS, turn on the orange‑cloud proxy for that CNAME, and automatically get an Orange‑to‑Orange (O2O) setup. Traffic would first hit the customer’s zone (applying their Cloudflare rules) and then pass through Bubble’s zone (applying Bubble’s rules) before reaching Bubble’s origin.
You can still use Cloudflare Workers as a workaround.
Yes, it’s more advanced, but doable if you really want to go that route.
Added: Don’t know what plan you’re on, but access to your own Cloudflare WAF, advanced bot mode, and custom rate limiting rules, I think, are only available if you’re on an Enterprise plan or…
you can use the workarounds like Cloudflare Workers."
Cloudflare Workers won’t be able to process http request/responses without Proxy being enabled. WAP is included in all plans, but more advanced features do require a paid plan.
It’s my understanding Cloudflare Workers only runs on traffic that actually passes through Cloudflare’s proxy network (the “orange‑cloud” setting). If you leave a DNS record in DNS‑only mode (grey cloud), requests go straight to your origin and never hit Cloudflare’s edge, so no Worker can intercept, rewrite, or redirect them.
I should have been more specific with my prior comment:
Cloudflare Workers won’t be able to process http request/responses without Proxy being enabled.
I need to be able to control the WAF, cache, rate limiting, and other security features to keep bots from flooding our Bubble site and burning through our WUs. I also need URL rewrites and redirects features. These features require the Orange cloud to work:
Yes, your DNS record for your domain needs to be in ‘DNS only’ (grey cloud) mode to point to Bubble; the Cloudflare Worker itself runs at Cloudflare’s edge.
Then, when a request comes in for your domain, Cloudflare’s edge network intercepts it to run the Worker, as long as a Worker route is configured. The Worker then acts as the proxy, making an internal request to your Bubble app.
So, the traffic does hit Cloudflare’s edge for the Worker to process it, and lets you do logic like rate limiting before the request ever reaches Bubble.
You are correct. Cloudflare does need to be active on a zone (orange cloud) in order to enable cloudflare workers
The best way to prevent bots, is ultimately use things like hCaptcha, or what I do is make it so any public API’s have rate limits, and limited access to unauthorized (not logged in) users.
The best way to setup your own cloudflare zone, is to setup your own server with a CNAME, then redirect your traffic to your main domain. I use NextJS for this purpose, but you can easily use express or other API routers. This fully allows you to setup your own cloudflare, and have full control of your domain.
Ok, we’ll go with your thing since there is more than one way to fix something: The zone itself needs to be active on Cloudflare for Workers to run.
My point is that a Worker operates at Cloudflare’s edge regardless of the specific DNS record’s cloud status.
So, even with a grey-clouded record for Bubble to avoid conflict, the Worker still intercepts and processes requests at the edge before sending them to Bubble, letting you add custom security.
So, we’ll agree to disagree on the best way, although I don’t think it’s the best practice.
Added: You’re adding extra costs, scalability issues, and just an overall extra thing that isn’t needed.
I don’t think I’ve ever tested this out. However, I do know that doing the CNAME method might be the best method (for anyone), to allow full control over the domain, like workers, redirects, caching, etc. However, requires some “know-how”. So to break it down to make it work the way you’re suggesting:
Using a Worker with a Route pattern that matches requests to your domain
Having this Worker make a fetch request to your Bubble app
Implementing security logic in the Worker before forwarding requests
Technically, this would allow the Worker to run at Cloudflare’s edge while technically keeping your main DNS record as grey-clouded.
My approach (separate server):
Provides maximum flexibility and control
Requires maintaining additional server infrastructure
Serverless, no additional infrastructure to maintain
Potentially simpler deployment
May have some limitations compared to a full proxy
Potentially lower cost (depends on traffic volume)
Either approach would be effective. The choice would depend on your technical expertise, willingness to manage additional infrastructure, and specific security requirements.
Hmm.. Maybe I can make you guys an app that’ll handle this
@matthewpomar I suggest using this method. I am setting up something similar to shift my production app (3 years running) to a Cloudflare managed domain since CF doesn’t currently manage .sg domains.
It’ll be easier to park your Bubble app to a subdomain. Then orange cloud your root domain and route it to a Worker. Do your thing then route to the subdomain when you need to hit your Bubble app.
I appreciate the lively discussion and suggestions for how to get around Bubble’s Cloudflare limitations.
Hopefully Bubble monitors this forum and see this thread, and understands their customers are jumping through hoops and additional cost/added complexity to gain control over what Cloudflare offers, in a lot of cases for free, out of the box.
