What happened

Vercel’s WAF for Blob is now in beta. Vercel Blob is Vercel’s file storage service, the place an app keeps uploaded images, PDFs, or other files separate from its code. A WAF, or web application firewall, is a set of rules that filters incoming traffic before it reaches your app, blocking or slowing down requests that look abusive.

Until now, Vercel’s WAF only covered your deployment, the app itself. It now extends the same rule types, deny, challenge, and rate limit, to requests hitting your Blob store too, with no changes to your code, your blob URLs, or the @vercel/blob package your app already uses. Every blob is already served through Vercel’s CDN (the network of servers that delivers your files from a location close to the requester), so this turns on protection at that existing layer rather than adding a new one.

Turning it on is a single dashboard toggle: open your Blob store, go to Settings, then Protect your store. From there you build rules that match on IP address, country, request path, and more, and they take effect immediately.

What each rule type actually does

Three of the four rule types work differently than a simple on/off switch, and the difference matters for storage traffic specifically:

  • Deny returns an error immediately and stops the request before any file data transfers, so you don’t pay for bytes you’re blocking anyway.
  • Rate limit returns a “too many requests” response once a single client crosses a threshold you set, useful for stopping one script from hammering an expensive file repeatedly.
  • Challenge makes the requester prove it’s a real browser before the file is served, the same kind of check you’ve likely hit on other sites when a page asks you to wait a moment before it loads.

That last one is where the beta’s real gotcha lives.

The gotcha: challenge rules can block your own server code

A challenge rule needs a web browser to solve it. During this beta, if your rule matches a request that comes from your own server code (for example, a piece of backend code that calls @vercel/blob to fetch a file on a user’s behalf, instead of the user’s browser fetching it directly), that request has no browser to solve the challenge with, and Vercel blocks it. Nothing changes about your code; the file simply stops loading, and it can look like your storage is broken rather than like a rule you set is working as designed.

Vercel’s own guidance is direct about this: use challenge rules for browser traffic, not server-to-server calls. If your app does anything server-side with Blob, a challenge rule aimed too broadly can quietly break that path.

There’s a second limitation worth knowing before you set anything up: one rule set covers every store you protect on your team, and Vercel connects protected stores to a shared project behind the scenes. You can’t currently write a different set of rules for one sensitive store versus another lower-risk one. If you protect multiple stores, whatever you configure applies everywhere.

One more scope note: Vercel’s standard rule set for detecting attacks against application logic (the OWASP Core Ruleset) isn’t supported here, because it’s built for app traffic, not for file delivery. The deny, challenge, and rate-limit rules above are what’s available for Blob specifically.

Who should care

This matters if you store user-generated files, like uploads, exports, or generated images, in Vercel Blob and have ever seen unexpected bandwidth costs or slow responses from something scraping or hammering those files. It matters less if your Blob store only holds files your own app serves privately with no public URL exposure.

What builders should do next

Before turning anything on, find out whether any of your own server code fetches from Blob, not just your browser-facing app. If it does, hold off on challenge rules, or scope them narrowly to paths you know only browsers hit, like a public download link.

After you enable a rule, test both paths: load the protected file from a browser like a normal visitor would, and separately trigger whatever server-side code in your app also reads from that store. If the server-side call starts failing or timing out where it worked before, a challenge rule is very likely the cause, and rate limit or deny is probably the better fit for that specific path.

If you protect more than one store, remember the rule set is shared across all of them right now. A rule tuned for your public-download store will also apply to a quieter, internal-only store, so write rules with your loosest, most public store in mind until Vercel adds per-store scoping.

End of article