Comment protéger les téléversements de fichiers dans les formulaires web

Un formulaire avec pièces jointes peut faciliter une demande de devis, un retour, une candidature ou un incident technique. Toutefois, chaque fichier reçu ouvre un parcours qui ne s’arrête pas au navigateur : il peut passer par l’application web, WordPress, le stockage, une plateforme d’assistance, un CRM ou une automatisation. Si ce parcours n’est pas défini, une pièce jointe légitime peut provoquer des erreurs opérationnelles ou exposer des systèmes qui n’étaient pas préparés à la recevoir.

L’objectif ne devrait pas être d’accepter n’importe quel fichier puis de réagir ensuite, mais d’autoriser uniquement les pièces jointes indispensables à chaque processus. Cette approche équilibre l’expérience et la protection : l’utilisateur connaît les règles avant d’envoyer le formulaire et l’entreprise dispose de contrôles cohérents pour valider, conserver, partager et supprimer les documents.

Le problème consiste à accepter plus de pièces jointes que nécessaire

Tous les formulaires n’ont pas besoin de la même capacité de téléversement. Un contact commercial peut nécessiter une image ou un PDF pour évaluer un projet ; un retour peut nécessiter des photographies ; une candidature peut nécessiter un CV. En revanche, un formulaire d’inscription ou une demande brève n’a normalement pas besoin de fichiers. Recenser tous les points de téléversement, y compris ceux créés par des plugins, des espaces privés et des outils d’assistance, aide à éliminer les pièces jointes superflues avant d’ajouter des contrôles techniques.

OWASP recommande une défense en profondeur : limiter les extensions à celles qui sont nécessaires à la fonction métier, restreindre le téléversement aux utilisateurs autorisés lorsque cela est pertinent, fixer des limites de taille et conserver les fichiers en dehors du répertoire public de l’application ou sur un hôte séparé. Ces mesures doivent être considérées comme un ensemble, et non comme une simple vérification d’extension. [1]

• Examinez les formulaires de contact, d’assistance, de retours, de candidatures et les portails privés.
• Supprimez le téléversement de fichiers lorsqu’une description, un numéro de commande ou un lien sécurisé permet de résoudre le processus.
• Distinguez les formulaires publics, les formulaires authentifiés et les processus internes.

Créez un contrat de téléversement pour chaque processus

La mesure la plus utile consiste à créer une fiche simple par formulaire : finalité de la pièce jointe, formats admis, poids maximal par fichier, nombre maximal de fichiers, personnes autorisées, destination de stockage, durée interne de conservation et responsable du processus. Ce contrat transforme une option générique « joindre un fichier » en une règle opérationnelle que les équipes techniques, marketing et de service client peuvent examiner ensemble.

À titre d’exemple hypothétique, un formulaire de retour pourrait autoriser jusqu’à trois images pour documenter l’état d’un produit, tandis qu’un formulaire d’assistance pourrait autoriser un PDF ou une capture d’écran. Il n’est pas judicieux de copier les mêmes limites dans les deux cas : elles doivent découler de ce qu’une personne doit fournir pour mener à bien cette démarche, de la capacité technique disponible et des outils qui recevront ensuite le fichier.

• Documentez une brève justification pour chaque format autorisé.
• Définissez qui peut télécharger chaque pièce jointe et dans quel contexte.
• Désignez un responsable chargé d’examiner les changements de plugins, d’intégrations ou d’exigences du processus.

Validez sur plusieurs couches et communiquez des erreurs claires

L’extension visible par l’utilisateur ne suffit pas à déterminer si un fichier est acceptable. L’application doit appliquer une liste courte de formats autorisés, traiter avec précaution les noms inhabituels ou encodés, vérifier le type et, lorsque cela est approprié, la signature du fichier. Elle doit également générer son propre nom interne au lieu de réutiliser le nom transmis. Cela réduit la dépendance à des données contrôlées par la personne qui effectue le téléversement. [1]

Les limites doivent exister de manière cohérente dans le navigateur, l’application, le serveur, le stockage et l’intégration ultérieure. OWASP identifie comme un risque l’absence de limites de taille, de temps, de mémoire ou d’opérations, et recommande également de limiter la fréquence selon les besoins de chaque endpoint. Lorsqu’une requête dépasse la taille admise, le code HTTP 413 permet d’indiquer que le serveur ne la traitera pas ; le message affiché doit préciser la taille maximale ou les formats autorisés sans révéler de détails internes. [2] [3]

• Appliquez une limite individuelle et un nombre maximal de pièces jointes par envoi.
• Évitez de traiter ou de décompresser des fichiers sans contrôler les ressources que cette tâche peut consommer.
• Expliquez comment corriger l’envoi : par exemple, réduire la taille ou choisir un format autorisé.

Séparez la réception, le stockage et l’intégration

Un fichier reçu ne devrait pas être accessible publiquement ni exécutable par défaut. Il est préférable de le stocker en dehors du répertoire public du site web et de proposer les téléchargements par un mécanisme qui vérifie les autorisations et le lien avec le dossier correspondant. Cette séparation est particulièrement importante si le site utilise WordPress, une boutique en ligne ou des composants tiers : la commodité d’un lien direct vers un fichier ne doit pas remplacer le contrôle d’accès. [1]

Avant de transmettre une pièce jointe à un CRM, à un service d’assistance ou à une automatisation, vérifiez que seul un fichier déjà validé et associé à un identifiant d’opération est transmis. Si la destination externe échoue, le flux doit enregistrer l’état et permettre une reprise contrôlée, sans dupliquer les envois ni perdre le lien avec la demande initiale. Dans les formulaires authentifiés qui modifient l’état de l’application, il faut également prévoir des mesures contre les requêtes forgées, comme des jetons, une validation de l’origine ou d’autres contrôles adaptés à l’architecture. [4]

• Ne publiez pas d’URL prévisibles permettant de télécharger des pièces jointes.
• Conservez des autorisations distinctes pour les personnes qui reçoivent, examinent et téléchargent les documents.
• Testez ce qui se produit si le CRM ou le système d’assistance ne répond pas.

Enregistrez, testez et améliorez sans affecter l’activité

Pour enquêter sur les défaillances et les incidents, enregistrez le quand, le où, le qui et le quoi de l’événement : identifiant de la demande, formulaire, résultat de validation, motif du rejet, taille, type détecté, destination et état de traitement. OWASP inclut le téléversement et le traitement de contenus fournis par les utilisateurs parmi les événements pertinents à enregistrer et à surveiller. Il n’est pas nécessaire de stocker le contenu de la pièce jointe dans les journaux ; le faire peut augmenter l’exposition d’informations sensibles. [5]

Avant d’activer des modifications, testez dans un environnement autorisé ou dans un périmètre expressément convenu. Utilisez des fichiers inoffensifs pour vérifier un téléversement valide, un fichier trop volumineux, un format non autorisé, un nom inhabituel et une défaillance simulée de la destination externe. Examinez ensuite les messages reçus par l’utilisateur, les journaux et la reprise du processus. Un audit de protection web peut aider à examiner ce parcours complet et à prioriser les corrections défensives sans transformer le test en une activité perturbatrice.

• Examinez périodiquement les rejets répétés et les erreurs de transmission vers des systèmes externes.
• Vérifiez que les limites correspondent sur toutes les couches techniques.
• Mettez à jour la fiche de téléversement lorsque le processus métier ou une intégration change.

Questions fréquentes

Suffit-il de bloquer des extensions telles que .exe ou .php ?

Non. Bloquer certains formats peut faire partie de la protection, mais ne remplace pas une liste de formats nécessaires, des validations du fichier, des noms internes générés par l’application, des limites de ressources, un stockage non public et des contrôles d’accès aux téléchargements.

Quelle taille maximale dois-je autoriser dans un formulaire ?

Il n’existe pas de valeur universelle. Elle doit correspondre à l’usage légitime du formulaire, au nombre de fichiers autorisé, à la capacité de traitement et aux limites des systèmes connectés. L’important est d’appliquer une règle cohérente et d’expliquer clairement la limite avant ou pendant l’envoi.

Puis-je envoyer automatiquement les pièces jointes au CRM ?

Oui, si le flux est conçu pour que l’intégration ne reçoive que des fichiers déjà validés et puisse tracer chaque opération. Il est conseillé de contrôler les autorisations, d’enregistrer l’état de transmission et de définir ce qui se passe si le CRM rejette le fichier ou n’est pas disponible.