Gravity Forms : téléversement de fichiers, sécurité du dossier et limites serveur

Accepter des fichiers par formulaire répond à des besoins parfaitement légitimes : une candidature avec son curriculum, une demande de devis avec un plan, un dossier avec ses justificatifs. Le champ se pose en trois clics et il ouvre en même temps une porte vers le serveur, avec des conséquences qui vont du désagrément à l'incident sérieux. Les fichiers déposés atterrissent dans un répertoire accessible, portent parfois des noms devinables, contiennent souvent des données personnelles et peuvent, dans les cas les plus graves, être exécutés. Cet article passe en revue les réglages à poser, les limites serveur à ajuster et les questions de conservation qui accompagnent inévitablement ce type de champ.

Configurer le champ correctement

Les réglages du champ lui même constituent la première ligne de défense, et ils sont souvent laissés à leurs valeurs par défaut, nettement trop permissives pour un usage réel. La création d'un formulaire et ses réglages généraux sont présentés dans notre article sur l'installation et la création d'un formulaire Gravity Forms.

Restreindre les extensions

Le champ accepte une liste d'extensions autorisées, laissée vide par défaut, ce qui revient à tout accepter dans les limites de ce que le cœur tolère. Renseigner explicitement les extensions attendues, souvent deux ou trois, ferme immédiatement l'essentiel du risque. Cette liste doit être aussi courte que le besoin le permet : une candidature demande un document et pas une archive compressée. Chaque extension ajoutée par confort doit être justifiée par un usage réel constaté. Il vaut mieux ajouter une extension après une demande d'un utilisateur que d'en autoriser dix par anticipation.

Comprendre les limites de ce contrôle

La vérification porte sur l'extension du nom de fichier et non sur le contenu réel, ce qui signifie qu'un fichier renommé passe le filtre. Le cœur applique par ailleurs ses propres contrôles sur les types autorisés, ce qui constitue une seconde barrière. Ces deux protections se complètent sans être infaillibles, ce qui justifie les mesures de protection du répertoire décrites plus loin. Le raisonnement doit toujours partir du principe qu'un fichier inattendu finira par arriver. C'est cette hypothèse qui rend indispensables les directives de configuration décrites plus bas, indépendamment des réglages du champ.

Limiter la taille

Une taille maximale doit être fixée sur le champ, en cohérence avec ce que le serveur accepte réellement. Une valeur généreuse posée sur le champ mais refusée par le serveur produit un échec sans message clair, situation particulièrement frustrante pour l'utilisateur. Cinq à dix mégaoctets couvrent la quasi totalité des besoins documentaires. Au delà, un service de dépôt externe est préférable à un formulaire. Un lien vers un espace de partage, saisi dans un champ de texte, évite tous les problèmes liés au transit par le serveur.

Limiter le nombre de fichiers

Le champ multiple accepte plusieurs fichiers et son nombre maximal doit être fixé explicitement. Sans limite, une soumission peut déposer des dizaines de fichiers et saturer l'espace disque. Cette limite se choisit en fonction du besoin réel, trois ou quatre suffisant dans la plupart des cas. Elle protège aussi contre les soumissions automatisées cherchant à consommer des ressources. Combinée à une protection contre les envois automatisés, elle referme l'essentiel de ce risque.

Le téléversement différé

Le champ propose un mode dans lequel le fichier part immédiatement, avant la soumission du formulaire, ce qui améliore l'expérience et crée un effet de bord : des fichiers arrivent sur le serveur même lorsque le formulaire n'est jamais validé. Ces fichiers orphelins s'accumulent et doivent être purgés. Le comportement doit donc être choisi en connaissance de cause plutôt que subi. Une purge planifiée des dépôts non rattachés à une entrée règle ce point. Elle doit tourner régulièrement, faute de quoi le répertoire accumule des fichiers dont personne ne connaît l'origine.

Rendre le champ obligatoire ou non

Un champ de téléversement obligatoire bloque les personnes n'ayant pas le document sous la main au moment de la demande, ce qui produit des abandons. Le rendre facultatif, avec une possibilité d'envoi ultérieur, améliore sensiblement le taux de complétion sur les formulaires longs. Ce choix relève de l'expérience utilisateur et il a un effet mesurable. Il mérite d'être discuté avec les personnes qui traitent les demandes. Elles savent en général quelle proportion de dossiers arrive incomplète et ce que cela leur coûte en relances.

Protéger le dossier de dépôt

C'est le point le plus important de tout le sujet et celui qui est le plus souvent laissé en l'état, notamment parce que rien ne signale le problème tant qu'il ne se produit pas.

Où atterrissent les fichiers

Les fichiers reçus sont déposés dans un sous répertoire dédié du dossier des médias, organisé par année et par mois. Ce répertoire est situé sous la racine web, donc accessible par une adresse, comme l'ensemble du dossier concerné. Son fonctionnement général est décrit dans notre article sur le dossier uploads de WordPress et son fonctionnement. Cette accessibilité est le point de départ de toutes les précautions qui suivent. Elle surprend beaucoup de gestionnaires de sites, qui imaginent les pièces jointes stockées dans un espace réservé.

La protection par nom aléatoire

L'extension ajoute une chaîne aléatoire au nom des fichiers déposés, ce qui rend leur adresse difficile à deviner. Cette protection est réelle et elle constitue le seul obstacle sur une installation par défaut. Elle ne résiste pas à une adresse qui fuite, par un journal, un partage de lien ou un moteur de recherche. Elle doit donc être considérée comme un complément et non comme une protection suffisante. Une adresse partagée dans un échange de courriels finit fréquemment par circuler bien au delà du destinataire initial.

Interdire l'accès direct

Une directive de configuration interdisant l'accès au répertoire de dépôt supprime le problème à la racine. Sur un serveur classique, quelques lignes dans un fichier de configuration local suffisent ; sur d'autres, la directive se pose dans la configuration du site. Les fichiers restent alors accessibles aux personnes autorisées via un point d'entrée contrôlé par l'extension, qui vérifie les droits. C'est la mesure qui distingue une installation correcte d'une installation exposée. Elle demande de vérifier ensuite que le téléchargement depuis l'administration fonctionne toujours, ce qui est le seul effet de bord à surveiller.

Empêcher l'exécution

Au delà de l'accès direct, une directive interdisant l'exécution des fichiers dans ce répertoire ferme le scénario le plus grave, celui d'un fichier exécutable déposé puis appelé. Cette protection doit couvrir l'ensemble du dossier des médias et pas seulement le répertoire de dépôt. Elle est indépendante du formulaire et elle relève de la configuration générale du serveur. Sa mise en place est rapide et son absence est fréquente. Elle protège au passage contre bien d'autres scénarios que le formulaire, notamment les dépôts effectués par une extension compromise.

Les permissions du répertoire

Le répertoire doit être accessible en écriture au processus du serveur web et à personne d'autre. Des permissions trop larges, posées pour résoudre rapidement un problème de dépôt, laissent une porte ouverte durablement. Les principes applicables sont détaillés dans notre article sur la manière de gérer chmod et chown sous Linux pour un site Web. Un contrôle après chaque intervention sur le serveur évite les régressions. Une restauration de sauvegarde ou une migration réinitialise parfois ces permissions sans que personne ne le remarque.

Sortir les fichiers de la racine web

La solution la plus propre consiste à déposer les fichiers hors du répertoire accessible publiquement, ce qui rend toute adresse directe impossible. Cette configuration demande un réglage spécifique et elle n'est pas proposée nativement par toutes les versions. Elle se justifie pleinement dès que les fichiers reçus contiennent des données sensibles, dossiers médicaux, pièces d'identité, documents financiers. C'est la configuration à viser sur ce type de formulaire. Lorsqu'elle n'est pas possible, l'interdiction d'accès direct constitue un substitut acceptable, à condition d'être vérifiée.

Les limites du serveur

La moitié des problèmes signalés sur ce type de champ ne vient pas de l'extension mais des réglages du serveur, dont les valeurs par défaut sont souvent inférieures à ce que le formulaire annonce.

La taille maximale de téléversement

Une directive limite la taille d'un fichier reçu, avec une valeur par défaut couramment fixée à deux mégaoctets sur les hébergements mutualisés. Un formulaire annonçant dix mégaoctets échouera donc silencieusement au delà de deux. Cette valeur doit être relevée dans la configuration, ce qui n'est pas toujours possible sans intervention de l'hébergeur. Le contrôle se fait depuis l'écran de santé du site, qui affiche les valeurs effectives. Comparer cette valeur à celle annoncée sur le champ avant la mise en ligne évite des échecs incompréhensibles pour les utilisateurs.

La taille maximale de la requête

Une seconde directive limite la taille totale de la soumission, tous champs confondus. Elle doit être supérieure à la taille maximale de fichier multipliée par le nombre de fichiers autorisés, plus une marge. Un formulaire acceptant quatre fichiers de cinq mégaoctets demande donc au moins vingt cinq mégaoctets sur cette directive. Cet écart entre les deux valeurs est la cause la plus fréquente d'échecs sur les champs multiples. Le symptôme est caractéristique : un fichier passe, deux passent, le troisième fait échouer la soumission entière.

Le nombre de champs acceptés

Une directive limite le nombre de variables reçues dans une soumission, avec une valeur par défaut de mille. Un formulaire long comportant de nombreux champs répétés peut la dépasser, ce qui tronque silencieusement les données reçues. Ce cas est rare et particulièrement déroutant, puisque le formulaire paraît fonctionner tout en perdant des champs. Il se diagnostique en comptant les champs envoyés. Les formulaires comportant des sections répétables sont les premiers concernés, chaque répétition multipliant le nombre de variables.

Le temps d'exécution

Le traitement d'une soumission comportant des fichiers volumineux peut dépasser la durée maximale d'exécution autorisée, notamment lorsque des traitements d'image ou des envois vers un service externe s'ajoutent. Le symptôme est une page blanche ou une erreur serveur après une longue attente. Relever cette limite pour le seul traitement concerné est préférable à un relèvement global. Ce point mérite d'être vérifié dès que des fichiers importants sont acceptés. Un test avec un fichier proche de la taille maximale autorisée suffit à révéler le problème avant la mise en ligne.

La mémoire disponible

Le traitement d'une image volumineuse consomme une mémoire proportionnelle à sa taille en pixels et non à son poids sur disque. Une photographie de vingt millions de pixels peut demander plusieurs dizaines de mégaoctets, au delà de la limite par défaut de certains hébergements. Un dépassement produit une erreur fatale sans message exploitable pour l'utilisateur. Le redimensionnement à la réception, lorsqu'il est possible, réduit fortement ce risque. Il allège en outre considérablement l'espace consommé sur la durée, les photographies constituant l'essentiel du volume reçu.

L'espace disque

Un formulaire recevant régulièrement des pièces jointes consomme de l'espace de façon continue, et cette consommation est rarement surveillée. Un hébergement saturé provoque des erreurs sur l'ensemble du site, pas seulement sur le formulaire. Une surveillance de l'espace restant, avec une alerte à un seuil, évite la découverte brutale. La purge régulière des pièces anciennes est l'autre volet de cette question. Les deux mesures se complètent, la surveillance signalant l'urgence et la purge traitant la cause.

Conservation et exploitation

Les fichiers reçus contiennent presque toujours des données personnelles, ce qui déplace le sujet du terrain technique vers celui des obligations applicables.

Définir une durée

Une pièce jointe reçue pour traiter une demande n'a pas vocation à être conservée indéfiniment. La durée doit être définie en fonction de la finalité poursuivie, une candidature non retenue et un dossier client n'appelant pas les mêmes délais. Nous ne sommes pas juristes et cette question relève d'un conseil compétent selon votre activité. Techniquement, cette durée doit être appliquée automatiquement plutôt que laissée à la bonne volonté. Une purge automatique posée dès la mise en ligne évite d'avoir à traiter plusieurs années d'accumulation un jour.

Purger réellement les fichiers

La suppression d'une entrée depuis l'interface ne supprime pas systématiquement les fichiers associés sur le disque, selon les versions et les réglages. Ce point mérite une vérification explicite, en supprimant une entrée de test et en regardant si le fichier subsiste. Une purge des fichiers orphelins doit compléter la purge des entrées. Sans elle, les données restent présentes alors que l'on croit les avoir effacées. C'est le genre d'écart entre l'intention et la réalité qu'un contrôle de conformité met en évidence immédiatement.

Le cas des notifications par courriel

Une pièce jointe transmise par courriel se retrouve dans la boîte du destinataire, hors de tout dispositif de purge. Cette copie échappe à la durée de conservation définie sur le site et elle est rarement prise en compte. Transmettre un lien vers l'entrée, plutôt que le fichier lui même, résout ce point tout en évitant les problèmes de taille de message. C'est la pratique à privilégier sur les formulaires recevant des documents sensibles. Elle demande simplement que les personnes concernées disposent d'un accès à l'administration, ce qui est généralement le cas.

Sauvegardes et copies

Les fichiers reçus figurent dans les sauvegardes du site, qui les conservent selon leur propre politique de rétention. Une purge sur le site vivant ne touche pas les sauvegardes, ce qui prolonge la conservation effective. Cette réalité doit être connue et prise en compte dans la politique retenue. Elle constitue l'angle mort le plus courant de ce type de mise en conformité. La durée de conservation des sauvegardes doit donc être cohérente avec celle retenue pour les pièces jointes.

Restreindre l'accès aux entrées

Les personnes disposant d'un accès à l'administration peuvent consulter les entrées et télécharger les pièces jointes. Restreindre cette capacité aux seuls rôles qui en ont besoin limite l'exposition. Cette restriction se règle dans les capacités de l'extension et elle est souvent laissée ouverte à l'ensemble des administrateurs. Un formulaire de candidature n'a aucune raison d'être consultable par le prestataire chargé du référencement. Cette revue des accès mérite d'être refaite une fois par an, les comptes s'accumulant au fil des interventions.

Documenter le dispositif

Une note indiquant quels formulaires reçoivent des fichiers, où ils sont stockés, combien de temps ils sont conservés et qui y accède permet de répondre à une question sans enquête. Elle sert autant à la conformité qu'à la reprise du site par un tiers. Cette documentation tient sur une page et elle doit être relue lors de chaque ajout de formulaire. Son absence transforme chaque demande d'information en recherche approximative. Elle doit indiquer, pour chaque formulaire, la durée de conservation retenue et la personne qui accède aux fichiers déposés.