En-têtes de sécurité pour applications web : guide de configuration
Configurez les en-têtes de sécurité essentiels pour votre application de transfert. CSP, HSTS, X-Frame-Options et plus contre les attaques web.
Les en-têtes de sécurité sont des champs de réponse HTTP qui indiquent aux navigateurs comment contraindre le comportement d'une page. Pour une application de transfert de fichiers effectuant du chiffrement AES-256-GCM côté client, six en-têtes comptent davantage que les autres : Strict-Transport-Security pour forcer HTTPS, Content-Security-Policy pour bloquer l'injection de scripts, X-Frame-Options pour prévenir le clickjacking, Referrer-Policy pour stopper les fuites de fragments d'URL, Permissions-Policy pour désactiver les API navigateur inutilisées, et Cross-Origin-Opener-Policy pour isoler le contexte de navigation. Configurez-les correctement et vous bloquez 80 % des attaques côté client sans modifier une seule ligne de JavaScript.
HSTS et la liste de préchargement
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload indique aux navigateurs de ne plus jamais se connecter en HTTP simple, pendant deux ans. La directive preload vous qualifie pour la liste de préchargement HSTS de Chrome (hstspreload.org), qui est livrée avec le navigateur — même la toute première requête vers votre domaine passe par HTTPS, éliminant la fenêtre MITM initiale. L'inscription est sans retour ; la suppression prend des mois. Testez d'abord avec max-age=300 pendant quelques jours. Un service de transfert sans préchargement HSTS est à un détournement DNS d'un faux formulaire d'upload.
Une Content Security Policy qui fonctionne réellement
La CSP est l'en-tête le plus difficile à déployer et le plus précieux. Une politique stricte pour une application de transfert ressemble à : default-src 'none'; script-src 'self' 'wasm-unsafe-eval'; connect-src 'self' https://upload.hexatransfer.com; style-src 'self'; img-src 'self' data:; font-src 'self'; frame-ancestors 'none'; base-uri 'none'; form-action 'self'. Pas de scripts inline, pas d'eval sauf pour wasm, aucune connexion tierce. Déplacez tous les gestionnaires d'événements inline vers addEventListener dans des fichiers externes. 'wasm-unsafe-eval' est nécessaire pour libsodium.js ; sans lui, Argon2id ne s'instanciera pas.
Intégrité des sous-ressources sur chaque bundle
Si votre JavaScript est chargé depuis un CDN comme jsDelivr ou unpkg, ajoutez des attributs integrity="sha384-..." sur chaque balise script. Le navigateur refuse d'exécuter les scripts dont le hash ne correspond pas — un CDN compromis ne peut pas silencieusement pousser un bundle avec une backdoor. Pour les scripts hébergés sur votre propre domaine, l'intégrité des sous-ressources est moins critique mais reste défendable. Associez-la à la directive require-sri-for script style de la CSP (obsolète mais toujours honorée par Chrome) ou imposez-la via le pipeline de build. HexaTransfer publie les hashes par version pour que les utilisateurs paranoïaques puissent vérifier manuellement.
X-Frame-Options et frame-ancestors
Les attaques de clickjacking chargent votre page d'upload dans un iframe transparent par-dessus une autre page, trompant les utilisateurs pour qu'ils cliquent sur « envoyer » sur un fichier qu'ils ne voulaient pas partager. X-Frame-Options: DENY bloque tout encadrement ; le remplacement moderne est Content-Security-Policy: frame-ancestors 'none'. Envoyez les deux — les navigateurs plus anciens n'honorent que l'en-tête legacy, les plus récents préfèrent la CSP. N'utilisez jamais SAMEORIGIN pour une application de transfert ; vous n'avez aucune raison légitime d'encadrer l'interface d'upload depuis une autre page.
Referrer-Policy pour stopper les fuites de fragments
Les navigateurs suppriment les fragments d'URL (la partie #key=... où réside votre clé de déchiffrement) des en-têtes Referer par défaut, mais la partie chemin continue à fuiter. Referrer-Policy: no-referrer bloque toutes les informations de référent — pas d'en-tête Referer sur les liens sortants, pas de fuites cross-origin, pas d'empreinte d'URL par des traceurs externes. Pour une page de téléchargement à /d/7Kj9xQmN2vP8rBwLsE4fT#k=abc, cela empêche le slug de fuiter vers tout domaine externe sur lequel l'utilisateur clique. Définissez-la à l'échelle du site via l'en-tête ; ne comptez pas sur le rel="noreferrer" lien par lien.
Permissions-Policy pour la défense en profondeur
Si votre application n'utilise pas la caméra, le microphone, la géolocalisation ou l'API USB, refusez-les explicitement : Permissions-Policy: camera=(), microphone=(), geolocation=(), usb=(), bluetooth=(), accelerometer=(), magnetometer=(), gyroscope=(), payment=(). Une XSS qui a réussi à passer la CSP ne pourra toujours pas activer la webcam pour filmer l'utilisateur. Cet en-tête est peu coûteux à déployer, n'a aucun impact UX pour un workflow de transfert de fichiers, et signale aux auditeurs sécurité que vous avez réfléchi à la sandboxisation.
En-têtes d'isolation cross-origin
Pour accéder aux minuteries haute résolution et à SharedArrayBuffer (nécessaires à certaines implémentations wasm crypto), les navigateurs exigent l'isolation cross-origin via Cross-Origin-Opener-Policy: same-origin et Cross-Origin-Embedder-Policy: require-corp. Ces en-têtes préviennent également les attaques par canal auxiliaire de type Spectre qui pourraient faire fuiter des clés AES depuis des origines adjacentes. La contrepartie : les ressources tierces embarquées (vidéos YouTube, paiement Stripe) ne fonctionnent plus à moins de servir Cross-Origin-Resource-Policy: cross-origin. Pour une application de transfert à usage unique sans embeds tiers, l'isolation est gratuite.
Cache-Control pour les pages sensibles
La page de confirmation de téléchargement peut afficher une clé de déchiffrement éphémère ou un jeton de session. Empêchez la mise en cache : Cache-Control: no-store, must-revalidate et Pragma: no-cache. Ne comptez pas sur no-cache seul — cela autorise la revalidation auprès de l'origine, ce qui signifie que la mise en cache a quand même lieu. Pour le bundle JavaScript de la page d'upload, c'est l'inverse : max-age long avec des noms de fichiers hashés par contenu (/js/main-a7b3c9.js) pour que la mise en cache CDN fonctionne sans maux de tête d'invalidation. Appliquez les en-têtes chirurgicalement par chemin.
X-Content-Type-Options et le reniflage MIME
X-Content-Type-Options: nosniff empêche les navigateurs de deviner les types MIME en fonction du contenu. Sans cela, un fichier .txt uploadé par un attaquant contenant <script> pourrait être rendu comme du HTML lors du téléchargement. Pour un service de transfert servant des téléchargements contrôlés par l'utilisateur, combinez nosniff avec Content-Disposition: attachment; filename="..." pour que le navigateur télécharge plutôt que d'afficher. Validez le nom de fichier contre les traversées de répertoire (../../../etc/passwd) côté serveur ; ne faites jamais confiance aux métadonnées d'upload à des fins autres que l'affichage.
Surveillance et rapports CSP
Déployez la CSP en mode report-only d'abord, collectez les violations à un endpoint report-uri pendant une semaine, corrigez les problèmes légitimes, puis appliquez. Utilisez Content-Security-Policy-Report-Only pour l'observation, basculez sur Content-Security-Policy pour l'application. L'endpoint de rapport reçoit des POST JSON décrivant chaque violation : URI bloquée, directive violée, fichier source, numéro de ligne. Des services comme Report URI ou un Sentry auto-hébergé les collectent. Examinez-les chaque semaine — les vraies attaques apparaissent sous forme d'URI bloquées inhabituelles que vous n'avez jamais vues.
Évaluer votre configuration
Passez votre URL de production à travers securityheaders.com et Mozilla Observatory. Une note A ou A+ n'est pas la perfection mais c'est le minimum acceptable. La plupart des concurrents dans le transfert de fichiers obtiennent B ou moins parce qu'ils oublient Permissions-Policy ou autorisent 'unsafe-inline' dans la CSP. Un petit service peut facilement surpasser le score d'en-têtes de sécurité de WeTransfer ; les en-têtes ne coûtent rien à ajouter, et le bilan pour les conversations « pourquoi votre CSP n'est-elle pas stricte » avec les auditeurs SOC 2 est plus court quand vous avez commencé strict.
Essayez sur hexatransfer.com — gratuit, sans compte, jusqu'à 10 Go.
Envoyez vos fichiers volumineux en toute sécurité avec le chiffrement de bout en bout
Transférez des fichiers jusqu'à 10 Go gratuitement avec le chiffrement de bout en bout. Aucun compte requis. Vos fichiers sont chiffrés dans votre navigateur avant l'envoi — personne d'autre ne peut les lire.
Envoyer un fichier