Workers are smooth and useful as ■■■■, easy and slick. - plans are resonable too.
Only one problem
Say im on free plan and my worker url is abc.workers.dev
I have 100,000 requests
but even if a request is invalid, a worker counts the request.
So taking the cap of 1000requests per minute, can ddos a worker out in 100 minutes by sending requests non stop
All you need is its url.
Imagine you are on a paid plain, 10 million requests and your credit card added and no cap per minute
You go to sleep at 11PM and by the time you wake up your card is NIL with a massive cloudflare bill with nothing to boot.
All because a user knows your worker url and send invalid requests.
Maybe i have this figured out wrong but this is what i observed and we are now scared to try the free plan let alone the paid plain.
There’s optional (paid) rate limiting that you can apply in front of the worker to avoid this from happening. What we do to avoid these issues, is logging each request in an analytics tool and when a threshold is reached, we put activate the request limiting and start adding abusing IPs to the firewall.
It does require a bit of engineering and finding analytics that can handle the load though…
(In general, there’s no way to see that you’re using a worker and not just using the CF CDN network)
AFAIK, billed requests are KV read/writes, not worker requests. You can have as many requests free of charge as you want if you are on the Workers Unlimited plan. To reduce the potential bill if your worker scripts read from KV, you can use Cache API to store some information locally. Cache API is also free without limits.
I think it is not a huge problem in the real world as Cloudflare’s DDoS handling would step in in front of a worker in the event of an unexpected spike. And while I don’t know how they would handle the situation, in general, you pay for legitimate traffic and not malicious/attack traffic.
If you have concerns I would reach out to Cloudflare directly to discuss the potential billing implications.
In addition there is the consideration that every DDoS solution costs more the more you get attacked, so this is really the best case scenario out there.
You could also add firewall rules challenging more troubling traffic before it hits the worker. The there is rate limiting, but it’s not less expensive than simply allowing the worker to run. 50 cents per million is nothing, rate limiting pricing is 50 per 100k, on good traffic, 10 times more expensive.
CF won’t always step in though i.e. layer 7 application level DDOS attack which Cloudflare won’t 100% always be able to mitigate without user configuration via CF Firewall rules/rate limiting.
Yes more specific CF Firewall rules for your specific web application is needed to reduce the bad traffic hitting your CF Workers.
Yes while CF Worker billing would increase in a DDOS attack situation, the cost is less than similar sized DDOS mitigation solutions at the origin server side i.e. upgrading server and/or adding DDOS mitigation at origin level. However, this is provided the CF Worker solution has equivalent DDOS mitigation i.e. CF Worker caching which offloads hitting the origin’s dynamic PHP endpoints in the form of guest full page HTML cache Worker solution. But if the CF Worker isn’t doing such DDOS mitigation by offloading load for origin’s dynamic PHP servers, then the CF Worker would incur additional cost and have no benefit for DDOS mitigation.
Also while a passive solution, you can also setup usage notifications for workers
At the end even with “servers” you have fixed costs and then it scales if you get attacked, increasing costs. The difference being that you have bigger steps in pricing, but there are costs in everything, for the provider itself there are costs.