Vercel WAF Now Protects Blob Storage in Beta

Vercel has extended its Web Application Firewall to cover Blob storage, with the feature now in public beta on all plans. The same rules that protect deployment traffic, including deny, challenge, and rate limit, can now be applied to blob URLs through a single dashboard toggle. Because blobs already route through Vercel's CDN, there is no new proxy to configure and no changes required to existing code or blob URLs.

What happened

Detail	Fact
Feature	Vercel WAF protection for Blob stores
Status	Public beta
Plans	All Vercel plans
Setup	Single toggle in Blob store Settings dashboard
Code changes required	None
OWASP Core Ruleset	Not supported for blob traffic

Vercel’s WAF can now sit in front of a Blob store. Until now, the firewall only covered deployment traffic. Blobs already pass through Vercel’s CDN, so adding protection is a matter of connecting the store to the firewall, not routing requests through a separate proxy.

When you enable protection, Vercel links your store to a shared project called vercel-blob-default-project on your team. You write rules there using the standard rule builder, and they apply immediately across every protected store on that team.

What rules are available?

The supported rule types mirror what is already available for deployment traffic:

• Deny: Returns a 403 and stops the request before any data is transferred.
• Challenge: Serves a browser challenge. Requests that fail it are blocked.
• Rate limit: Returns a 429 when a client exceeds your defined threshold.
• Redirect and log: Behave the same as they do for deployment traffic.

Rules match on IP address, country, path, and other standard attributes. The OWASP Core Ruleset is excluded because it targets dynamic application traffic, not static object delivery.

How to set it up

1. Open your Blob store in the Vercel dashboard.
2. Go to Settings, then select “Protect your store.”
3. Author rules in the standard WAF rule builder. They take effect immediately.

There is one important constraint: the single ruleset covers every protected store on your team. You cannot write rules that apply only to one specific store.

What are the beta limitations?

During the beta period, setup is dashboard-only with no API or CLI access. The bigger constraint affects server-side code: challenge rules require a browser to complete the verification step. Any @vercel/blob server-side request that matches a challenge rule will be blocked rather than challenged. Vercel recommends using challenge rules only for browser-initiated traffic during this period.

Why it matters

Blob stores are often used to serve images, downloads, and other assets that can be expensive to deliver at scale. Without a WAF in front of them, a single abusive IP or scraper can rack up significant bandwidth and storage costs. Blocking at the edge with a Deny rule stops the request before a byte is transferred, which is a meaningful cost protection for teams with large or frequently accessed stores.

Geo-restrictions are also now practical for blob assets. Teams that need to comply with regional distribution rules, or simply want to limit downloads to specific markets, can add a country-based deny rule without touching their application code.

For teams already using Vercel for web development, this fills a gap: your app endpoints were protected, but the files those apps served were not. Now they can be.

Our take

This is a sensible extension of existing infrastructure rather than a new product. Vercel is reusing the same rule engine and builder that developers already know, which keeps the learning curve near zero. The one-ruleset-per-team constraint will frustrate larger teams that want per-store policies, but for most small-to-medium projects it is not an issue.

The challenge rule caveat is worth flagging loudly: if you use @vercel/blob in server-side code and accidentally apply a challenge rule to those paths, your server requests will fail silently with a block rather than a challenge. Test any challenge rules carefully against your actual traffic patterns before enabling them on a live store.

If you are running an e-commerce build on Vercel and serving product images or downloadable assets from Blob, this is worth turning on now, even in beta. Rate limiting expensive assets alone can prevent runaway bandwidth bills from bot traffic.

What to do about it

1. Audit which Blob stores serve public assets that could be abused by scrapers or bots.
2. Enable WAF protection via the store Settings toggle in the Vercel dashboard.
3. Start with a Deny rule for known bad IP ranges or unwanted countries before adding broader rules.
4. Add a rate limit rule on high-cost assets such as large downloads or video files.
5. Avoid challenge rules on any path that your server-side code accesses via @vercel/blob until Vercel adds server-side challenge support.

One ruleset covers all your stores, so plan your rule logic carefully before enabling protection across multiple stores simultaneously.

Source: Vercel Blog