Téléversement sécurisé en e-commerce : pièces jointes, quarantaine et diffusion

Un fichier téléversé reste une entrée non fiable

Les photos de retour, visuels de personnalisation, documents B2B et tickets d’assistance font du téléversement une fonction commerciale. Ils font aussi de chaque pièce jointe un contenu non fiable : nom, extension et type déclaré viennent du client et ne prouvent pas que les octets sont sûrs. Le risque ne se limite pas aux logiciels malveillants. Un fichier peut viser un parseur vulnérable, saturer le stockage ou l’analyse, remplacer un objet existant ou devenir public avant la fin des contrôles.

La réponse n’est pas un antivirus isolé, mais une chaîne de défense en profondeur. Comme choix d’architecture fail-closed, nous recommandons des états distincts pour l’autorisation, les contraintes applicatives, le stockage privé, la quarantaine, l’analyse, la validation et le téléchargement. Dans ce modèle, chaque étape n’accepte l’objet qu’après le résultat de la précédente et conserve assez de preuves pour identifier l’auteur du dépôt, le dossier concerné et la version des règles appliquées.

Définir le périmètre et la politique avant le code

Classer les parcours et leurs conséquences

Dressez un inventaire par cas d’usage : extensions nécessaires, taille maximale, nombre de fichiers par demande, utilisateurs autorisés, conservation, destination et destinataires. Une photo de retour, un PDF fiscal et un fichier source destiné à l’impression personnalisée n’ont pas le même profil. Évitez un endpoint universel muni d’une liste trop permissive ; associez une politique explicite au contexte métier et enregistrez sa version.

Définissez au minimum des états comme requested, uploaded, quarantined, accepted, rejected et expired. Seul accepted autorise la mise à disposition. Une erreur, un délai dépassé ou une indisponibilité du scanner ne vaut pas résultat sain : l’objet reste isolé pendant que le système décide d’un nouvel essai ou d’un nouveau dépôt. Cette sémantique empêche une panne de contourner la quarantaine.

Valider l’intention et les octets par couches

Liste autorisée, limites et noms générés

Utilisez une liste d’extensions réellement nécessaires au parcours et appliquez-la après normalisation du nom, en traitant casse, doubles suffixes et caractères ambigus. Le Content-Type transmis par le navigateur est un signal utile, mais il n’est pas fiable seul. Comparez-le à l’extension, à la signature ou aux magic bytes et au résultat d’un parseur adapté au format. La cohérence ne rend pas le fichier inoffensif ; elle réduit les entrées inattendues avant les contrôles suivants.

Imposez les limites avant et pendant le transfert, puis refusez tout contenu partiel ou supérieur à la politique. N’utilisez jamais le nom d’origine comme clé de stockage. Générez un identifiant aléatoire imprévisible, conservez le nom fourni uniquement comme métadonnée normalisée et bloquez traversal, séparateurs de chemin et collisions. Vérifiez aussi que le dossier appartient à l’utilisateur autorisé et protégez l’initialisation contre les actions cross-site selon l’architecture applicative.

Séparer transfert, stockage et autorisation

Envoi direct avec permissions minimales

Une URL présignée permet au navigateur d’envoyer l’objet directement vers le stockage sans faire transiter ses octets par le serveur applicatif. Elle ne constitue pas une décision de sécurité complète : son détenteur peut l’utiliser pendant sa validité et selon ses conditions, avec les permissions de l’identité qui l’a créée. Émettez donc une URL de courte durée, liée à une clé nouvelle et à une seule intention, après avoir autorisé l’utilisateur, la commande ou le ticket.

La zone d’entrée doit rester privée et séparée de la destination servie. Le client ne choisit librement ni bucket, ni chemin public, ni clé définitive. Un dépôt sur une clé existante peut remplacer l’objet ; l’unicité générée évite cette collision. À la confirmation, le backend vérifie présence, taille et métadonnées attendues, associe l’objet au dossier métier et le place en quarantaine sans créer d’URL publique.

Concevoir le flux de quarantaine et d’analyse

Faire de chaque résultat un état opérationnel

Une mise en œuvre opérationnelle possible utilise un worker isolé qui lit l’objet avec des droits réduits au périmètre nécessaire, calcule une empreinte, reconnaît le type réel et exécute les contrôles prévus. Un moteur comme ClamAV peut fonctionner comme processus ou service, mais il exige des signatures maintenues et des limites explicites pour archives, récursion, durée et taille décompressée. Lorsque le format et le risque le justifient, une normalisation ou une reconstruction du contenu peut réduire les éléments actifs sans remplacer validation et analyse.

Enregistrez version du moteur et des signatures, empreinte, durée, résultat et code interne de refus. N’exposez pas de diagnostic qui aiderait à adapter une charge. Une détection place l’objet dans un état non diffusable et déclenche la procédure prévue ; une erreur technique le maintient en quarantaine. Évitez les tentatives infinies : prévoyez une politique bornée, une file d’erreurs et une alerte si l’âge ou le volume des objets isolés dépasse les seuils internes.

Ne diffuser que les objets acceptés

Téléchargement médié et en-têtes cohérents

Comme choix d’architecture fail-closed, le passage à accepted doit être atomique et auditable, et non une copie implicite côté client. Pour un document privé, autorisez chaque téléchargement selon compte, commande, rôle et expiration, puis fournissez un lien temporaire ou transmettez le flux. Envoyez un Content-Type cohérent avec le format vérifié et envisagez Content-Disposition: attachment lorsque le contenu doit être téléchargé plutôt qu’affiché inline. Le nom proposé reste indicatif et doit être assaini.

X-Content-Type-Options: nosniff bloque une requête destinée à un script ou une feuille de style lorsque le type MIME déclaré n’est pas valide pour cette destination ; pour les autres types de réponse, il désactive le MIME sniffing. C’est une couche de défense, pas un scanner de pièces jointes. La protection vient de l’ensemble formé par stockage privé, autorisation, type vérifié et réponse contrôlée. Si certains médias doivent être publics, diffusez une version dérivée et régénérée sur un chemin séparé, jamais l’original intact, et empêchez son exécution sur l’origine applicative.

Mesurer ensemble sécurité et fiabilité

Suivez demandes initialisées, dépôts terminés, octets reçus, refus de politique, types incohérents, résultats d’analyse, erreurs, délais dépassés et temps en quarantaine. Segmentez par parcours et version de politique, pas par données personnelles inutiles. Ajoutez des mesures de capacité : profondeur de file, âge de l’objet le plus ancien, espace utilisé, nouvelles tentatives et proportion de téléchargements autorisés ou refusés.

Reliez les événements avec des identifiants techniques qui ne contiennent ni nom original ni secret. Une hausse des erreurs peut signaler des signatures obsolètes, un parseur instable, un abus ou une évolution légitime du client. Tableaux de bord et alertes doivent permettre de suspendre un type, d’arrêter les nouvelles initialisations ou de maintenir tous les objets en quarantaine sans les perdre ni ouvrir de voie non contrôlée.

Tester incidents, suppression et reprise

Testez fichiers vides, doubles extensions, types incohérents, archives protégées ou trop imbriquées, transferts interrompus, objets hors limite, collisions, scanner indisponible et téléchargement par un compte non autorisé. Vérifiez qu’aucun résultat autre que sain ne rende l’objet disponible. Testez aussi expiration, suppression, audit et reprise. Comme autre choix fail-closed, configurez la reprise afin que restaurer une sauvegarde ne réintroduise pas automatiquement une pièce jointe refusée ou expirée.

Une chaîne robuste rend chaque frontière visible : le client propose, l’application autorise, le stockage isole, les contrôles classent et la diffusion décide de l’accès. Pour concevoir stockage, files et contrôles autour de votre architecture, découvrez nos services pour systèmes e-commerce. Pour transformer des dépôts dispersés en processus vérifiable, contactez AE Digital Agency et définissons politiques, quarantaine et critères de diffusion.