Cloudflare Workers Billing & Security: Thoughts on 401 Responses?
Original message was deleted
SA hot topic that often comes up is the fear of a Denial of Wallet (DoW) attack where a malicious actor intentionally triggers high usage/billing by sending a massive number of requests to a service.
Given this concern, would it be a good solution for Cloudflare not to bill for any Worker request that returns a 401 Unauthorized status code?
Pro-Argument:
This would significantly mitigate the risk of a DoW attack, as attackers targeting a misconfigured or secure endpoint would be generating 401 responses, effectively hitting a "free" rate limit for that specific attack vector.
Con-Argument:
Could this open up a new abuse vector where bad actors intentionally trigger 401 responses (perhaps via bots or scraping) to use Cloudflare's edge compute and network resources for free, essentially shifting the operational cost?
What are your thoughts on this policy change? Would it be a net positive for security and developer confidence? Or would the risk of abuse outweigh the benefit?
Given this concern, would it be a good solution for Cloudflare not to bill for any Worker request that returns a 401 Unauthorized status code?
Pro-Argument:
This would significantly mitigate the risk of a DoW attack, as attackers targeting a misconfigured or secure endpoint would be generating 401 responses, effectively hitting a "free" rate limit for that specific attack vector.
Con-Argument:
Could this open up a new abuse vector where bad actors intentionally trigger 401 responses (perhaps via bots or scraping) to use Cloudflare's edge compute and network resources for free, essentially shifting the operational cost?
What are your thoughts on this policy change? Would it be a net positive for security and developer confidence? Or would the risk of abuse outweigh the benefit?
Iwould it be a good solution for Cloudflare not to bill for any Worker request that returns a 401 Unauthorized status code?While it may sound good in theory, the cost of a Worker comes from the work it's doing (no pun intended), i.e. CPU time that it is consuming on Cloudflare's network.
If they did this then they'd be effectively doing it at-cost because it still costs them CPU/memory/storage/etc in order to compute a response which would then be wasted.
SWhat about the idea of using a Pre-Worker JWT Check that uses a Secret Store Key.
Intercepting a call to something like/api/* moves the authorization check to a lightweight function that executes before the main, expensive Worker logic.
Unauthorized requests are dropped early, resulting in a minimal CPU cost for the 401 response. This would turn a potential Denial of Wallet attack into a negligible one, addressing the "cost of work" problem head-on.
Intercepting a call to something like/api/* moves the authorization check to a lightweight function that executes before the main, expensive Worker logic.
Unauthorized requests are dropped early, resulting in a minimal CPU cost for the 401 response. This would turn a potential Denial of Wallet attack into a negligible one, addressing the "cost of work" problem head-on.
SIt looks like AWS has implemented something similar recently for their Application Load Balancer: "This feature allows ALB to verify JSON Web Tokens (JWTs) included in request headers, validating token signatures, expiration times, and claims without requiring modifications to application code."
Can we have this functionality?
Can we have this functionality?
Amazon Web Services, Inc.
Discover more about what's new at AWS with Application loadbalancer support client credential flow with JWT verification
