Sécurité des téléversements pour apps prototype : protections pratiques

Ce qui peut mal tourner avec les téléversements dans un prototype

Les téléversements sont une voie d'attaque prisée parce qu'ils traversent beaucoup de frontières à la fois : votre appli, votre stockage, et tout ce qui lira ensuite le fichier. Un bouton « simple » d'envoi peut devenir un moyen d'exécuter du code dans un navigateur, de divulguer des fichiers privés ou d'exploser votre facture cloud.

La plupart des problèmes viennent des raccourcis de prototype. Les équipes font confiance à l'extension du nom de fichier (comme .png), sautent les vérifications quand un fichier est « assez petit », ou téléversent directement dans un bucket cloud partagé avec des permissions larges. Un autre raccourci courant est de servir le fichier téléversé depuis le même endroit où il a été stocké, sans réfléchir au contrôle d'accès ou au comportement du navigateur.

Quand les téléversements sont lâches, les conséquences sont prévisibles :

• Prise de compte (par exemple, un fichier qui déclenche un bug dans le traitement d'images/PDF)
• Fuites de données (un téléversement « privé » qui devient public, ou des utilisateurs pouvant deviner des URLs)
• Factures cloud élevées (fichiers volumineux, réessais répétés ou bots abusant votre endpoint)
• Atteinte à la réputation (malware hébergé sous votre domaine ou bucket)

Un modèle mental simple aide : tout flux de téléversement a quatre étapes — acceptation, validation, stockage, distribution.

• Acceptation est l'endroit où vous fixez des limites et bloquez les abus évidents.
• Validation est l'endroit où vous confirmez quel est réellement le fichier, pas ce qu'il prétend être.
• Stockage est l'endroit où les permissions comptent le plus, car un bucket mal configuré peut tout exposer.
• Distribution est l'endroit où les en-têtes et les vérifications d'accès empêchent votre appli de devenir un service d'hébergement de fichiers.

Exemple : votre prototype permet aux utilisateurs de « téléverser une photo de profil ». Un attaquant envoie avatar.png qui est en réalité du HTML ou un script. Si vous le stockez dans un bucket public et le servez avec le mauvais Content-Type, il peut s'exécuter dans le navigateur d'un autre utilisateur et voler des sessions.

Mettez d'abord des limites claires de taille et de débit

La plupart des incidents de téléversement commencent par « on ajoutera les limites plus tard ». Les limites sont parmi les contrôles les plus simples à ajouter, et elles vous protègent contre les factures surprises, les ralentissements et les abus.

Commencez par ce dont les utilisateurs ont vraiment besoin. Si vous n'avez besoin que de photos de profil, une limite de 5–10 Mo suffit généralement. Si vous acceptez des vidéos ou des fichiers de design, choisissez une limite supérieure volontairement et attendez-vous à ajouter plus de garde-fous.

Ne comptez pas sur un seul paramètre. Mettez des limites à plusieurs endroits pour qu'une mauvaise configuration ne casse pas tout :

• Une taille maximale stricte par fichier
• Une taille totale maximale par requête (pour éviter que 20 petits fichiers deviennent énormes)
• Des timeouts de téléversement
• Des plafonds quotidiens par utilisateur (fichiers/jour ou MB totaux/jour)
• Des limites de rafale (téléversements/minute)

Les timeouts comptent plus qu'on ne le croit. Sans eux, un attaquant peut faire couler des données lentement et bloquer vos workers serveur. Si vous utilisez des uploads pré-signés directement vers le stockage, fixez une courte durée d'expiration pour que l'URL ne soit pas réutilisable indéfiniment.

Rendez les messages d'erreur clairs pour que les vrais utilisateurs puissent corriger rapidement. Indiquez ce qui a échoué et quelle est la limite (par exemple « Fichier trop volumineux. Max 10 Mo. »). Séparez « trop de téléversements aujourd'hui » et « téléversement expiré » car ce sont généralement des causes différentes.

Validez le type réel du fichier (pas seulement le nom)

Un nom de fichier comme invoice.pdf ne vous dit presque rien. n'importe qui peut renommer invoice.exe en invoice.pdf et le téléverser. Traitez les extensions comme un indice, pas comme une règle.

Les navigateurs envoient aussi un type MIME déclaré (comme image/png). Vérifiez-le, mais ne lui faites pas confiance. C'est une donnée contrôlée par l'utilisateur.

Confirmez le type à partir du contenu du fichier

Utilisez les « magic bytes » (l'en-tête du fichier) pour identifier ce qu'est réellement le fichier. Un vrai PNG a une signature spécifique au début du fichier. Cela attrape les astuces courantes où le nom et le MIME disent une chose mais le contenu est autre.

Gardez la décision simple : n'acceptez que les types exacts que vous supportez et rejetez tout le reste. Une allowlist est plus sûre que d'essayer de bloquer les types « mauvais ».

Pour beaucoup de prototypes, une allowlist raisonnable de départ est image/jpeg, image/png et application/pdf. Ajoutez text/plain uniquement si vous avez un cas d'usage clair, et soyez prudent sur le rendu.

Méfiez-vous des ZIP et des formats Office

Les fichiers ZIP et les documents Office (DOCX/XLSX/PPTX) présentent un risque plus élevé parce qu'ils sont des conteneurs. Ils peuvent cacher des scripts, des macros ou des structures surprenantes. Si vous devez les accepter, traitez-les comme « nécessitant des vérifications supplémentaires » : limites plus strictes, scan anti-malware et absence de service direct.

Exemple concret : si quelqu'un téléverse profile.png mais que les magic bytes indiquent un exécutable Windows, rejetez-le immédiatement et logguez la tentative.

Traitez les noms de fichiers et chemins en toute sécurité

Beaucoup de bugs liés aux téléversements ne sont pas du malware. Ils viennent de la confiance excessive dans les noms de fichiers. Si votre appli utilise le nom fourni par l'utilisateur pour construire un chemin, un simple téléversement peut écraser des fichiers, casser des pages ou divulguer des données.

Considérez chaque nom de fichier comme une entrée non fiable. Les utilisateurs peuvent inclure des caractères de chemin, des caractères de contrôle ou des Unicode trompeurs qui semblent normaux à l'écran mais se résolvent différemment sur le disque.

Règles plus sûres pour les noms de fichiers

Le schéma le plus sûr est d'ignorer le nom donné par l'utilisateur pour le stockage. Générez un nom côté serveur (par exemple un ID aléatoire ou UUID), et conservez le nom original seulement comme texte d'affichage dans votre base de données après l'avoir nettoyé.

Règles pratiques qui évitent la plupart des problèmes de nommage :

• Générez votre propre nom de stockage et choisissez vous-même l'extension
• Supprimez les séparateurs de chemin (/, \\), les points initiaux et les caractères invisibles
• Normalisez l'Unicode pour que les ressemblances visuelles ne créent pas de doublons étranges
• Bloquez les doubles extensions (comme photo.jpg.exe)

Exemples d'entrées à prévoir : ../../app.env ou avatar.png\u202Egnp.exe. Si vous enregistrez ces noms directement, vous pouvez écrire en dehors du dossier prévu ou masquer un exécutable derrière un nom qui a l'air légitime.

Évitez de stocker les uploads dans des chemins publics

Ne stockez jamais les téléversements utilisateur dans le dossier public de votre appli. Placez-les dans un emplacement privé (bucket privé ou chemin disque privé), puis servez-les via un endpoint de téléchargement contrôlé.

Séparez aussi les uploads bruts des sorties traitées. Stockez l'original dans un emplacement, et les images redimensionnées ou aperçus convertis dans un autre. Cela facilite la gestion des permissions et le nettoyage.

Stockez les uploads en sécurité avec des buckets privés et des permissions strictes

Le mode le plus sûr par défaut est simple : traitez chaque téléversement comme privé tant que vous n'avez pas une raison claire de le rendre public. La plupart des « fuites de prototypes » arrivent parce que le stockage est mis en public-read pour la commodité et n'est jamais corrigé.

Séparez les uploads utilisateur des assets statiques de votre appli. Mettez le contenu utilisateur dans un bucket (ou conteneur) et les assets du site (logos, CSS, fichiers build) dans un autre. Ainsi une erreur de permission sur les uploads n'expose pas toute l'application, et votre pipeline de build ne peut pas écraser les fichiers utilisateurs.

Verrouillez qui peut écrire

Faites passer les uploads par un petit service côté serveur avec les moindres privilèges nécessaires. Ce service doit pouvoir écrire de nouveaux objets et lire uniquement ce dont il a besoin. Évitez les permissions qui permettent de lister tout, de supprimer tout ou de changer la politique du bucket.

Visez quelques valeurs par défaut ennuyeuses : objets privés, buckets séparés pour dev/staging/prod, chiffrement activé quand c'est supporté, et journaux d'audit activés pour les accès aux politiques et aux objets.

Permettez le téléchargement sans rendre les fichiers publics

Quand un utilisateur doit télécharger un fichier, utilisez des URL signées de courte durée générées par votre serveur. Cela donne un accès limité dans le temps sans rendre l'objet public.

Cachez les secrets côté client. N'envoyez pas de clés d'accès, permissions d'écriture ou tokens d'administration dans le code du navigateur.

Traitez et servez les uploads sans exposer les utilisateurs

Téléverser un fichier n'est que la moitié du risque. L'autre moitié est ce que votre appli fait ensuite : traitement, génération d'aperçus et distribution.

Une valeur par défaut sûre est de traiter chaque nouveau téléversement comme non fiable et de le mettre en quarantaine jusqu'à la fin des vérifications. Si quelque chose passe à travers, il ne sera pas servi publiquement par erreur.

Pour les images, évitez de servir l'original. Redimensionnez et ré-encodez (décoder l'image, puis l'écrire à nouveau en PNG ou JPEG). Cela élimine beaucoup de charges cachées et supprime les métadonnées problématiques.

Pour les documents, imposez des limites strictes sur le nombre de pages, la taille et le temps d'extraction. Les PDF et fichiers Office peuvent être énormes, imbriqués ou malformés. Échouez fermé si le traitement prend trop de temps. Si vous avez besoin d'aperçus, générer une image sûre est souvent plus sûr que rendre le document dans le navigateur.

Ne rendez jamais du HTML ou du SVG fourni par un utilisateur directement. Si vous devez les accepter, convertissez-les d'abord en un format sûr (comme une image raster) ou n'autorisez le téléchargement qu'avec des en-têtes empêchant l'exécution inline.

Lors de la distribution des fichiers, quelques règles couvrent la plupart des cas :

• Ne servez pas les uploads depuis l'origine principale de l'application
• Utilisez des URL signées ou un endpoint de téléchargement qui vérifie l'autorisation
• Forcez le téléchargement pour les types risqués et définissez des en-têtes empêchant l'exécution inline
• Suivez le statut (quarantaine, approuvé, rejeté, supprimé) et logguez les événements clés (utilisateur, IP, hash, décision)

Exemple : un fondateur téléverse un « logo.svg » pour une landing page. Si vous le rendez inline, il peut s'exécuter dans certains navigateurs. Si vous le convertissez en PNG et ne servez que le PNG, le risque chute fortement.

Options de scan anti-malware et compromis pratiques

Le scan anti-malware n'est pas toujours requis pour un prototype, mais il devient rapidement utile quand les uploads sont partagés avec d'autres utilisateurs, ouverts par votre équipe ou transformés en aperçus. Si votre appli gère des factures, CV, ZIP, fichiers Office ou tout contenu téléchargé, scanner est une partie pratique de la sécurité des téléversements.

Si les uploads ne sont que des images utilisées pour des avatars, vous pouvez parfois sauter le scan au début et réduire le risque en ré-encodant les images et en rejetant tout ce qui n'est pas une vraie image. Une fois que vous avez de vrais utilisateurs, le scanning est souvent une assurance peu coûteuse.

La plupart des équipes choisissent une des trois approches : scanning géré dans leur stack cloud, une API de scan tierce, ou un antivirus auto-hébergé dans un worker. Le « meilleur » choix est souvent celui que vous allez vraiment maintenir et surveiller.

Par défaut, il est prudent de scanner au téléversement avant tout traitement (thumbnailing, parsing, génération d'aperçus), et d'autoriser la distribution seulement après que le fichier soit marqué propre. Si vous ajoutez le scanning plus tard, scanner les fichiers « at rest » vous aide à nettoyer les données anciennes.

Quand un scan est positif, traitez-le comme un événement de sécurité, pas comme une erreur UI : bloquez l'accès immédiatement, mettez l'objet en quarantaine, notifiez le propriétaire et votre équipe, et conservez une piste d'audit (utilisateur, heure, hash, résultat).

Étape par étape : un flux d'upload sûr à implémenter

La bonne sécurité des téléversements consiste surtout à faire les mêmes vérifications ennuyeuses à chaque fois, dans le même ordre, avant qu'un fichier ne soit accessible par d'autres utilisateurs.

1) Recevoir dans une zone temporaire

Acceptez les uploads uniquement dans un emplacement temporaire (bucket temp ou dossier temp) qui n'est jamais public.

• Faites respecter les limites dès l'entrée : taille, nombre de fichiers, timeouts et limites de débit basiques
• Traitez le nom de fichier comme non fiable et générez votre propre nom de stockage
• Validez le type réel du fichier en utilisant les magic bytes et une allowlist

2) Inspecter, stocker et servir en sécurité

Avant que quoi que ce soit soit visible dans l'app, scannez et isolez. Si vous ne pouvez pas scanner encore, gardez privé et restreignez l'accès.

• Scanner et mettre en quarantaine ; si le scan échoue ou signale le fichier, ne l'attachez pas au contenu utilisateur
• Déplacez les fichiers approuvés dans un stockage privé avec des permissions serrées et des métadonnées claires (owner, purpose, created_at)
• Servez via des URL signées de courte durée ou un proxy qui vérifie l'autorisation

Mettez en place un nettoyage automatique. Expirez les uploads temporaires jamais utilisés et supprimez les fichiers anciens dont vous n'avez plus besoin. Cela empêche la croissance mystérieuse du stockage et réduit le blast radius.

Erreurs communes qui causent des accidents de buckets publics

La plupart des incidents « bucket public » ne sont pas des hacks sophistiqués. Ce sont des petits choix de commodité qui deviennent permanents puis sont copiés en production.

Une erreur classique est de régler tout le bucket en public juste pour que les aperçus fonctionnent durant une démo. Une autre est de retourner des URLs publiques directes depuis votre API parce que c'est plus simple que des URL signées ou un endpoint de téléchargement. Si les noms sont prévisibles (comme invoice.pdf), les gens peuvent les énumérer. Même si les noms sont aléatoires, un lien fuité devient une fuite permanente quand l'objet est public.

Quelques signaux d'alerte reviennent souvent :

• Un SDK cloud côté navigateur qui peut écrire dans le stockage
• Une clé avec des permissions larges « read/write everything »
• Des URL signées ou tokens qui finissent dans des logs ou analytics
• Des ACL « temporaires » copiées en production

Les schémas plus sûrs sont généralement tout aussi rapides :

• Gardez le stockage privé par défaut et servez via des URL signées ou votre appli
• Téléversez vers une zone privée « incoming », puis promouvez les fichiers approuvés
• Gardez les credentials côté serveur ; donnez aux clients des tokens d'upload étroits et de courte durée

Checklist rapide avant la mise en production

Si vous ne faites qu'une passe avant le lancement, concentrez-vous sur les contrôles qui empêchent les erreurs les plus coûteuses.

Limites et validation

• Imposer une taille maximale stricte côté serveur et ajouter des limites de débit basiques par utilisateur ou IP
• Vérifier le type de fichier avec les magic bytes, et considérer les mismatchs MIME comme suspects
• Ré-encoder les formats risqués quand c'est possible au lieu de servir les originaux

Stockage et accès

• Stocker les uploads dans un stockage privé par défaut, avec des rôles à moindre privilège
• Ne jamais embarquer les clés de stockage ou les secrets de signature dans le code frontend
• Si vous acceptez des PDF, Office, ZIP ou contenu externe, prévoyez le scan et la quarantaine

Réversibilité

• Avoir un kill switch : rotater les identifiants, révoquer les tokens, bloquer l'accès public au niveau de la politique du bucket
• Rendre la suppression rapide : supprimer un fichier et ses dérivés, et conserver des logs pour retrouver les utilisateurs impactés

Étapes suivantes si votre app construite par l'IA a déjà des risques de téléversement

Les prototypes générés par l'IA arrivent souvent avec des téléversements fonctionnels mais sans les garde-fous nécessaires pour la production. Les symptômes typiques sont des URLs publiques permanentes, des téléversements qui fonctionnent sans authentification, pas de taille max côté serveur, et des serveurs qui font confiance au MIME envoyé par le navigateur sans vérifier le contenu du fichier.

Si vous avez besoin que quelqu'un vérifie rapidement le risque, il aide de réunir : le repo (ou une copie minimale avec le code et la config d'upload), vos réglages de stockage (public/privé et règles d'accès), où vont les uploads (navigateur→bucket vs via votre serveur), quelques logs d'upload, les types de fichiers acceptés et les limites souhaitées.

Si vous avez hérité d'un code généré par des outils comme Lovable, Bolt, v0, Cursor, ou Replit, FixMyMess (fixmymess.ai) se concentre sur la réparation de ces blocages de production : checks d'auth manquants, validation faible, gestion unsafe des noms de fichiers, permissions cloud trop larges, et absence de portes de quarantaine ou de scan. Un audit de code gratuit suffit souvent à obtenir une liste concrète de corrections prioritaires, sans deviner.