Gumlet's lack of spending limits is a security risk because video bandwidth is an attacker-controllable resource. Anyone who can reach a video URL — through hotlinking, scraping, denial-of-wallet attacks, leaked signed URLs, or even a buggy player in your own code — can spend your money, with no upper bound. The attacker's cost per gigabyte is near zero while yours is the full overage rate, which creates a structural asymmetry: there is no authentication to bypass, no vulnerability to exploit, just playback. Gumlet's stated mitigations — bandwidth alerts and the eventual fail-stop when a payment fails — are not equivalent to a real cap. Alerts depend on a human responding in time, and the payment-failure stop only kicks in after an invoice already exists and a charge has failed. Neither protects you from owing the money. This matters most for small customers, who have no procurement leverage to negotiate write-offs and no operational maturity to monitor and respond at attack speed. A true spending limit would operate at the resource layer, letting the customer choose to go dark rather than be billed for unbounded usage — a tradeoff Bunny Stream and Cloudflare Stream already offer. Until Gumlet provides one, partial mitigations help but do not close the gap: lock down videos with signed URLs and domain restrictions, set aggressive low-threshold alerts paired with paging rather than email, and consider putting a low-limit virtual card on file as a soft ceiling. For anyone whose business cannot absorb a surprise five-figure invoice, the absence of a cap is a real exposure that deserves to be weighed when choosing a video provider.
