Mauvaises configurations de buckets cloud : vraies fuites, vrais coûts

Les mauvaises configurations du stockage cloud continuent de faire des ravages en 2026

Les mauvaises configurations de buckets de stockage cloud restent l'une des causes les plus fréquentes — et les plus évitables — de violations de données, exposant des millions d'enregistrements clients chaque année. Au premier trimestre 2026 seulement, les chercheurs en sécurité d'UpGuard et de Wiz ont documenté plus de 40 incidents publiquement divulgués impliquant des buckets AWS S3, Google Cloud Storage et des conteneurs Azure Blob mal configurés, laissant fuiter aussi bien des exports CRM internes que des contrats clients signés.

---

Ce qui s'est réellement passé : la vague de buckets exposés

En mars 2026, une plateforme e-commerce de taille intermédiaire desservant environ 380 000 clients a laissé un bucket S3 accessible publiquement en lecture. À l'intérieur : des fichiers CSV d'export de commandes complets incluant les noms des clients, adresses e-mail, adresses de livraison et données de paiement partielles — générés automatiquement par leur pipeline analytique et jamais protégés par des contrôles d'accès. Le bucket était public depuis au moins 74 jours avant qu'un chercheur ne le signale via HackerOne.

Un incident distinct, en avril 2026, a impliqué l'intégration logistique tierce d'un marchand Shopify. Leur prestataire de fulfillment stockait des fichiers de manifestes de préparation de commandes — contenant des données personnelles clients — dans un bucket GCS avec un accès en lecture allUsers. Le marchand ignorait l'existence de ce bucket ; il avait été créé par un script d'intégration fournisseur et n'apparaissait jamais dans leur propre console cloud.

Ce ne sont pas des cas isolés. C'est la norme. Le rapport Verizon DBIR 2025 a identifié la mauvaise configuration comme facteur contributif dans 21 % des violations impliquant des actifs cloud.

---

Pourquoi cela continue de se produire (surtout dans les applications vibe-codées)

La cause technique fondamentale est trompeusement simple : les paramètres par défaut du stockage objet ont évolué, mais les habitudes des développeurs n'ont pas entièrement suivi. AWS a rendu les buckets S3 privés par défaut dès avril 2023, et Google a fait de même pour les nouveaux projets. Mais cela ne vous protège pas si :

• Vos templates d'infrastructure-as-code sont antérieurs à 2023 et ont été copiés-collés dans de nouveaux projets
• Un SDK, plugin ou une intégration tierce crée son propre bucket lors de l'installation
• Votre pipeline CI/CD exporte des artefacts de build, des rapports de tests ou des dumps de base de données vers un bucket temporairement rendu public pour le débogage — et jamais reverrouillé
• Vous utilisez un générateur de code IA (Cursor, Copilot, v0) qui a construit une intégration de stockage à partir d'un exemple d'entraînement incluant acl: public-read

Ce dernier point est de plus en plus pertinent pour la sécurité du vibe coding. Lorsque les développeurs livrent rapidement à l'aide d'outils assistés par IA, le code d'infrastructure généré hérite souvent de patterns issus d'anciens dépôts publics. Une invite comme « configure les uploads S3 pour les avatars utilisateurs » peut produire du code fonctionnel qui rend également, silencieusement, l'intégralité du bucket lisible par le monde entier. L'application est livrée. Le bucket reste là.

La sécurité du code généré par IA exige le même niveau de scrutin que le code écrit à la main — sans doute davantage, car l'écart de confiance est plus élevé. Le code a l'air correct. Il compile. Il fonctionne. La mauvaise configuration est invisible jusqu'à ce que quelqu'un scanne l'environnement en production.

---

Les détails techniques : ce que « public » signifie vraiment

Pour un bucket S3, l'exposition peut survenir à plusieurs niveaux :

1. ACL du bucket : public-read accorde la liste et la lecture à des utilisateurs anonymes à l'échelle mondiale
2. Politique du bucket : une politique avec "Principal": "*" et "Action": "s3:GetObject" ouvre chaque objet indépendamment des paramètres ACL
3. Paramètres Block Public Access : le système à quatre indicateurs d'AWS (BlockPublicAcls, IgnorePublicAcls, BlockPublicPolicy, RestrictPublicBuckets) doit être entièrement activé pour prévenir de manière fiable toute exposition accidentelle
4. ACL au niveau de l'objet : même dans un bucket privé, des objets individuels peuvent être rendus publics si votre code d'upload passe ACL='public-read' par objet

GCS et Azure Blob disposent de modèles de permissions en couches équivalents. La conclusion : il n'existe pas d'interrupteur unique. Les mauvaises configurations se glissent entre les mailles lorsque les développeurs supposent que les paramètres au niveau du bucket se propagent de manière sûre à tous les objets et à tous les états futurs.

---

Ce qui est exposé quand un bucket fuit

Ce ne sont rarement que des photos. Dans les incidents réels, les fichiers présents dans les buckets mal configurés comprennent :

• Des exports de base de données planifiés chaque nuit pour la sauvegarde ou l'analytique (orders_2026-03-01.csv)
• Des rapports internes générés automatiquement par des outils BI et poussés vers un stockage « temporaire »
• Des documents téléversés par les utilisateurs : scans KYC, photos d'identité, accords signés
• Des artefacts de build et journaux contenant des clés API, tokens et chaînes de connexion à des bases de données intégrés dans des dumps de configuration
• Des exports de données CRM ou ERP déclenchés par des intégrations (les pipelines Salesforce → S3 sont extrêmement courants)

Une fois qu'un pattern d'URL de bucket est découvert — et ils suivent des conventions de nommage prévisibles comme company-name-exports, prod-backups-2026, media-uploads-staging — les attaquants en énumèrent le contenu de manière systématique. Des acteurs malveillants actifs mènent des campagnes continues d'énumération de buckets ; ce n'est pas théorique.

---

Comment renforcer la sécurité du stockage cloud dès maintenant

Pour AWS S3 :

# Activer les quatre indicateurs Block Public Access au niveau du compte
aws s3control put-public-access-block \
  --account-id YOUR_ACCOUNT_ID \
  --public-access-block-configuration \
  BlockPublicAcls=true,IgnorePublicAcls=true,\
BlockPublicPolicy=true,RestrictPublicBuckets=true

Pour votre IaC (exemple Terraform) :

resource "aws_s3_bucket_public_access_block" "secure" {
  bucket                  = aws_s3_bucket.main.id
  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

Bonnes pratiques opérationnelles :

• Auditez tous les buckets trimestriellement à l'aide de aws s3api list-buckets et de vérifications de politiques — pas uniquement les nouveaux
• Utilisez AWS Macie ou GCS Data Catalog pour classifier automatiquement les données sensibles qui arrivent dans le stockage
• Faites tourner les URL pré-signées ; ne les utilisez pas comme mécanismes de partage permanents
• Examinez les permissions de chaque intégration tierce lors de l'onboarding — les fournisseurs créent leurs propres ressources
• Si vous avez utilisé un générateur de code IA pour construire du code de stockage, vérifiez explicitement les paramètres ACL ligne par ligne avant le déploiement

---

Comment Scorra détecte cela avant les attaquants

Un stockage mal configuré n'est pas une vulnérabilité au niveau du code — c'est un problème d'état de l'infrastructure, ce qui le rend invisible aux outils d'analyse statique et à la revue de code. Vous ne le trouverez pas en lisant votre app.js. Vous le trouvez en scannant l'environnement en production.

Scorra surveille en continu la surface d'attaque exposée de votre application web, y compris les signaux pointant vers un stockage mal configuré — actifs accessibles publiquement, exposition de répertoires non intentionnelle, et en-têtes ou réponses d'erreur qui laissent fuiter des URL de ressources internes.

Pour les marchands Shopify et les propriétaires de sites WordPress utilisant des intégrations tierces qui interagissent avec le stockage cloud, ce type de scan automatisé est le seul moyen pratique de détecter ce que les scripts fournisseurs créent silencieusement.

Pour les développeurs pratiquant le vibe coding sécurisé — livrer rapidement avec l'assistance de l'IA — exécuter un scanner sur votre environnement déployé avant le lancement est l'équivalent d'une checklist de pré-vol. Le code peut sembler correct. C'est l'infrastructure en production qui compte.

Scannez votre application sur scorra.io avant que votre bucket ne devienne la prochaine divulgation HackerOne.