jules@halfnil:~$ cat ~/blog/vercel-waf-blob-fichiers-statiques.md

Vercel met un WAF devant Blob : les fichiers statiques aussi se protègent.

Vercel peut désormais filtrer et limiter le trafic vers Blob. Une petite annonce qui rappelle qu’un stockage de fichiers public reste une vraie surface d’attaque.

25 juillet 2026 · 4 min ·

Le 24 juillet 2026, Vercel a lancé en bêta la protection des espaces Vercel Blob par son pare-feu applicatif. Une case à cocher permet désormais d’appliquer aux fichiers les mêmes règles de blocage, de challenge et de limitation de débit qu’aux déploiements web, sans modifier le code ni les URL existantes. La fonctionnalité est annoncée sur tous les forfaits pendant la bêta (annonce officielle).

Dit comme ça, cela ressemble à une ligne de changelog assez mineure. En pratique, elle souligne un angle mort fréquent : un fichier statique public est aussi un endpoint public.

## Un CDN ne remplace pas un contrôle d’accès

Une image, une archive ou une vidéo stockée dans un bucket ne passe pas forcément par l’application. Une fois son URL connue, le client peut interroger directement le stockage et contourner les contrôles placés dans une route API : session utilisateur, quota métier, journalisation ou limite par compte.

Vercel Blob sert déjà les objets à travers le CDN de la plateforme. La nouvelle couche permet d’évaluer les requêtes en périphérie selon leur adresse IP, leur pays, leur chemin et d’autres propriétés HTTP. Une règle deny renvoie un 403 avant le transfert du fichier, tandis qu’une limitation dépassée produit un 429 (détails de l’annonce).

Ce n’est donc pas seulement une question de sécurité au sens « empêcher le vol d’un fichier ». Il s’agit aussi de protéger la disponibilité et la facture : scraper qui aspire toutes les images, robot qui recharge une grosse archive ou client défectueux qui boucle sur un téléchargement.

Le même découpage existe chez Cloudflare R2. Un bucket relié à un domaine personnalisé peut profiter du cache, du WAF et de la gestion des bots, mais Cloudflare précise qu’il faut désactiver l’URL publique r2.dev si elle reste accessible, sinon elle constitue un chemin direct qui contourne ces protections (documentation des buckets publics).

La règle générale est simple : toutes les URL permettant d’atteindre un objet doivent traverser la protection prévue.

## Ce que le WAF règle, et ce qu’il ne règle pas

Le nouveau WAF de Vercel peut bloquer une IP abusive, limiter les requêtes ou restreindre certains pays. Il ne transforme pas pour autant une URL publique en ressource privée.

Pour un fichier réellement réservé à un utilisateur, le bon outil reste généralement une URL signée et temporaire. Amazon S3 vérifie par exemple la date d’expiration au début de la requête, avec une durée pouvant atteindre sept jours lorsqu’elle est générée par certains SDK ou outils en ligne de commande (documentation des URL présignées). Cloudflare rappelle de son côté qu’une URL présignée doit être traitée comme un jeton porteur : toute personne qui la possède peut effectuer l’opération autorisée jusqu’à son expiration (documentation R2).

En pratique :

  • Les images publiques d’un blog peuvent garder des URL stables et profiter du cache.
  • Les exports, factures et sauvegardes doivent utiliser des liens courts, signés après authentification.
  • Les fichiers lourds méritent une limitation spécifique, distincte de celle des petites images.
  • Une ancienne URL publique doit être désactivée lorsqu’un domaine protégé est ajouté.
  • Les journaux doivent permettre de distinguer un succès du cache, un refus et un accès direct au stockage.

## Le même principe sur un VPS

Cette annonce n’impose évidemment pas de migrer vers Vercel. Sur un serveur auto-hébergé, NGINX fournit le module `limit_req`, qui limite le rythme des requêtes selon une clé, souvent l’adresse IP, avec une logique de leaky bucket.

nginx
limit_req_zone $binary_remote_addr zone=assets:10m rate=10r/s;

server {
    location /assets/ {
        limit_req zone=assets burst=30 nodelay;
        limit_req_status 429;
    }
}

Ce garde-fou convient à des fichiers publics servis par le reverse proxy. Pour du contenu privé, il faut encore vérifier l’autorisation dans l’application, puis laisser le serveur transmettre le fichier ou générer un lien temporaire.

C’est particulièrement pertinent pour un projet auto-hébergé comme Dashboard Home si celui-ci finit par distribuer des captures, des exports ou des sauvegardes. Le stockage ne doit pas devenir une porte latérale simplement parce qu’il ne contient « que des fichiers ».

## Une bêta encore limitée

La première version garde quelques contraintes : la configuration passe uniquement par le tableau de bord, tous les espaces protégés d’une équipe partagent le même jeu de règles et les challenges nécessitent un navigateur. Une requête serveur effectuée avec `@vercel/blob` sera donc bloquée si elle rencontre une règle de challenge. Le jeu de règles OWASP n’est pas disponible non plus, car il vise surtout le trafic applicatif dynamique (annonce Vercel).

Ce n’est pas un pare-feu magique. C’est plutôt une séparation plus propre entre trois besoins souvent mélangés : servir vite, contrôler qui télécharge et empêcher qu’un client consomme tout.

## Pour aller plus loin

Veille rédigée avec l'aide d'une IA — sources vérifiées et liées ci-dessus.