Reeve Bases de la sécurité
En-têtes de sécurité manquants : quand cela compte
Les en-têtes de sécurité manquants sont notre constat le plus fréquent. Contre quoi ils protègent, et quand ils comptent le moins dans votre rapport.
En bref
- Les en-têtes de sécurité manquants sont le constat le plus courant qui soit et, à eux seuls, ils ne disent presque rien sur la possibilité d'atteindre vos données.
- Nous avons scanné 30 998 applications en ligne. Deux sur trois de celles à qui il manquait des en-têtes n’avaient rien d’autre.
- Cela vaut quand même la peine de les corriger, après ce qui décide qui peut lire votre base de données.
- Sur certains domaines de builders, vous ne pouvez pas les poser vous-même, et les laisser est une réponse raisonnable.
Votre scan revient et presque toutes les lignes sont vertes. Une est ambre : certains en-têtes de sécurité du navigateur sont manquants. C’est la seule chose colorée de la page, donc cela ressemble à ce qu’il faut traiter en premier.
Voici la partie que la plupart des conseils sur le sujet ratent. Les en-têtes de sécurité manquants sont le constat que nous affichons le plus souvent et, à eux seuls, ils ne vous disent presque rien sur la possibilité pour quelqu’un d’atteindre vos données. Le traiter comme une intrusion revient soit à le corriger dans la panique avant ce qui décide vraiment qui lit votre base de données, soit à apprendre que les lignes ambre sont du bruit, ce qui est pire.
Entre le 12 et le 14 août 2026, nous avons passé les mêmes neuf vérifications externes sur 30 998 applications en ligne construites avec Lovable, Bolt, v0, Replit et Base44. Parmi les applications dont cette vérification a obtenu une réponse, il manquait au moins un en-tête à 30 756 sur 30 981. Les chiffres complets sont dans notre rapport de scan.
Les en-têtes de sécurité manquants sont-ils un problème ?
C’est un vrai trou et c’est presque toujours la ligne la moins urgente de votre rapport.
Un en-tête de sécurité est une courte instruction que votre serveur attache à chaque page qu’il envoie, adressée au navigateur du visiteur plutôt qu’au visiteur. Ne laisse pas un autre site mettre cette page dans un cadre. Ne devine pas de quel type de fichier il s’agit. Ne transmets pas mon adresse complète quand quelqu’un clique vers l’extérieur. Ce sont des notes à un assistant qui fait ce que n’importe quel site lui dit.
Le reste de votre rapport parle de serrures. Row Level Security est-il activé, y a-t-il une clé secrète dans votre code, un bucket de stockage liste-t-il son contenu : voilà ce qui décide qui peut atteindre vos données. On veut les notes et les serrures, et la note que vous n’avez jamais écrite n’est pas la raison pour laquelle on perd une base de données.
Notre notation en tient compte. Un en-tête manquant retire cinq points sur cent et ne plafonne rien, donc une application dont c’est le seul constat ressort à 95 et avec la note A.
Ce que nous avons trouvé sur 30 998 applications
Les en-têtes manquants sont apparus presque partout, et ils ont à peine bougé avec le reste du rapport.
25 821 de ces applications ont obtenu une réponse des neuf vérifications, et c’est le groupe où « rien d’autre n’allait mal » veut dire quelque chose. Parmi elles, il manquait au moins un en-tête à 25 606, et 215 avaient les cinq.
Sur les 25 606 applications à qui il manquait au moins un en-tête, 17 043 n’avaient rien d’autre. Deux sur trois. C’était le seul problème de leur rapport.
Lisez maintenant l’autre ligne, et c’est la partie qui nous a surpris. Sur les 215 applications qui avaient les cinq en-têtes posés, 145 avaient autre chose qui clochait. C’est un taux de vrais problèmes plus élevé que chez les applications à en-têtes manquants, et non plus faible.
Nous n’avons pas mesuré pourquoi, et la lecture honnête est étroite : quoi que ces scans aient trouvé d’autre, le constat sur les en-têtes ne l’a pas prédit. Une application avec un jeu parfait d’en-têtes n’était pas une application plus sûre dans nos données. L’explication la plus probable est que poser des en-têtes suppose que quelqu’un a configuré un vrai hébergement, ce qui suppose en général une application plus grosse avec plus de choses à rater, mais c’est une supposition et nous ne l’avons pas testée.
Si vous voulez voir quelles lignes votre propre application produit, le scan est gratuit, prend une vingtaine de secondes et ne demande aucun compte : scanner votre application.
Ce que fait vraiment chaque en-tête
Chacun éteint un comportement du navigateur qui est actif par défaut.
| En-tête | Ce qu’il dit au navigateur | Ce que son absence permet |
|---|---|---|
Content-Security-Policy | Depuis quels endroits cette page peut charger du code et des styles | Un script injecté peut envoyer des données n’importe où |
Strict-Transport-Security | Reviens toujours en HTTPS, jamais en HTTP simple | Une visite sur un réseau non fiable peut être rabaissée en HTTP simple |
X-Frame-Options | Ne laisse pas un autre site afficher cette page dans un cadre | Votre page peut être chargée de façon invisible dans celle de quelqu’un d’autre |
X-Content-Type-Options | Fie-toi au type de fichier que je t’ai donné et ne le devine pas au contenu | Un fichier déposé par quelqu’un peut être servi comme un tout autre type |
Referrer-Policy | Quelle part de cette adresse transmettre quand un visiteur clique vers ailleurs | Des URL complètes, avec tout ce qu’elles contiennent, atteignent des serveurs tiers |
Deux d’entre eux se recoupent, et le scanner en tient compte. Une
Content-Security-Policy contenant frame-ancestors fait le même travail que
X-Frame-Options, donc notre vérification compte l’un ou l’autre et n’exige pas
les deux.
Quand un en-tête manquant est tout le problème
Quand votre application a quelque chose qui vaut la peine d’être cliqué pendant qu’on y est connecté.
C’est le cas du clickjacking, et c’est le seul qui fonctionne sans aucune autre erreur. Quelqu’un charge votre application dans un cadre invisible sur une page qu’il contrôle et pose ses propres boutons par-dessus les vôtres, si bien qu’un visiteur déjà connecté clique sur ce qui ressemble à sa page et touche l’une de vos commandes : le bouton qui supprime un compte, valide un virement ou change une adresse e-mail.
Le visiteur est connecté, donc l’action porte sa session. Rien dans votre base de données n’a besoin d’être mal configuré. Ce qui rend la chose possible, c’est qu’on n’a jamais dit au navigateur de refuser.
Referrer-Policy a une version plus petite de la même forme. Si une page à vous
en session connectée porte quelque chose d’identifiant dans l’URL et pointe vers
un hébergeur d’images ou un script d’analytics, l’adresse entière voyage avec le
clic. Celui qui tient cet autre serveur voit où était votre utilisateur.
Les trois autres sont conditionnels. Ils comptent quand quelque chose a déjà mal
tourné, et leur travail est de garder ça petit. Une Content-Security-Policy
limite ce qu’un script injecté peut faire de son accès. X-Content-Type-Options
compte si des inconnus peuvent vous déposer des fichiers.
Strict-Transport-Security couvre celui qui utilise votre application sur un
réseau qu’il ne contrôle pas.
Ai-je besoin d’en-têtes de sécurité ?
Oui. Ils coûtent peu, et ils viennent après les constats qui décident qui peut lire votre base de données.
L’ordre qui découle de la mesure ci-dessus : d’abord tout ce qui est critique ou élevé dans votre rapport, les en-têtes ensuite. Si votre rapport ne porte que cette ligne, comme c’était le cas pour 17 043 des applications scannées, alors les en-têtes sont en tête de votre liste par défaut.
Deux des cinq ne coûtent rien à poser correctement.
X-Content-Type-Options: nosniff et
Referrer-Policy: strict-origin-when-cross-origin tiennent chacun sur une
ligne, n’ont pas de mauvaise valeur à choisir et ne peuvent pas casser une
application qui marche. X-Frame-Options: DENY tient aussi sur une ligne, et
mérite un coup d’œil d’abord si vous intégrez volontairement votre propre
application quelque part.
Content-Security-Policy est celui qui demande du vrai travail. Une première
tentative bloque en général quelque chose dont votre propre page avait besoin,
et le symptôme est une fonction qui cesse de marcher sans rien dire. Livrez-le
en Content-Security-Policy-Report-Only, qui vous dit ce qu’il aurait bloqué
sans rien bloquer, et lisez une semaine de rapports avant de l’activer.
Comment les ajouter
Dans ce qui sert réellement votre application à internet, et ce n’est souvent pas là où vous la construisez.
La plupart des builders déploient vers un hébergeur qui est propriétaire de la
réponse, donc le réglage vit là-bas. Sur Vercel, c’est headers dans
vercel.json. Sur Netlify et Cloudflare Pages, c’est un fichier _headers à la
racine de ce que vous publiez. Derrière le proxy de Cloudflare, c’est une
Transform Rule. Si vous tenez votre propre serveur, c’est votre configuration
nginx ou Caddy.
Ce qu’il faut savoir des en-têtes une fois posés, c’est qu’ils disparaissent sans que personne y touche. Passer à un domaine à vous, mettre un proxy devant, changer d’hébergeur, modifier une configuration de framework : les en-têtes que vous avez ajoutés vivent à l’un de ces endroits, et chacun de ces mouvements peut les laisser en arrière. Rien ne vous prévient. La page continue de marcher, et le réglage n’est plus là.
C’est pour ce genre de chose qu’existe Reeve Monitor. Il repasse la vérification complète toutes les heures sur trois applications au plus, surveille la disponibilité toutes les 60 secondes et vous prévient quand un résultat change, au lieu d’attendre que vous regardiez. Monitor surveille et rien de plus, donc si vous voulez en plus une copie de votre base de données quelque part où votre builder ne peut pas l’atteindre, c’est Care, et cela couvre Supabase.
Quoi faire maintenant
Que faire
- Lisez d’abord le reste de votre rapport. Si quelque chose y est marqué critique ou élevé, c’est là qu’est le travail, et les en-têtes attendent.
- Posez aujourd’hui
X-Content-Type-Options: nosniffetReferrer-Policy: strict-origin-when-cross-origin. Une ligne chacun, rien à décider, rien à casser. - Posez
X-Frame-Options: DENYsi des gens se connectent à votre application et peuvent y faire quelque chose de lourd en un clic. - Gardez
Content-Security-Policypour la fin et démarrez-le en mode report-only, pour découvrir ce qu’il casse avant vos visiteurs. - Si vous êtes sur un sous-domaine de builder sans réglage d’en-têtes, laissez ce constat tranquille. Il n’est pas encore à vous.
- Vérifiez-les à nouveau après un changement de domaine, l’ajout d’un proxy ou un changement d’hébergeur. C’est là qu’ils disparaissent.
Les en-têtes valent un après-midi tranquille une fois le reste du rapport propre. Si vous préférez parcourir toute la liste dans l’ordre, la checklist de sécurité en 10 minutes couvre ce qu’il faut éteindre dans une application fraîchement lancée, et les constats qui décident vraiment qui lit votre base de données sont les premiers à évacuer.
FAQ
Mon scan dit que des en-têtes de sécurité sont manquants. Mon application a-t-elle été piratée ?
Non. Un en-tête manquant est un réglage qui n'a jamais été activé, et ce n'est pas la preuve que quelque chose s'est produit. Le constat n'implique personne qui aurait atteint vos données ou votre compte. Il décrit une instruction que votre site pourrait donner aux navigateurs qui le visitent et qu'il ne donne pas aujourd'hui.
Quel en-tête de sécurité poser en premier ?
X-Content-Type-Options et Referrer-Policy, parce que chacun tient sur une ligne, qu'aucun n'a de mauvaise valeur à choisir et qu'aucun ne peut casser une application qui fonctionne. Ensuite X-Frame-Options, si des gens se connectent à votre application. Ensuite Strict-Transport-Security. Content-Security-Policy en dernier, parce que c'est le seul des cinq qui demande une vraie réflexion et le seul qui peut empêcher vos propres scripts de tourner.
Je suis sur le domaine par défaut de mon builder et il n’y a aucun réglage pour les en-têtes. Et maintenant ?
Laissez-les. Quand votre application est servie depuis un sous-domaine de la plateforme, les en-têtes de réponse sont le choix de la plateforme et pas le vôtre, et il n'existe aucun fichier que vous puissiez ajouter pour les changer. Connectez un domaine à vous si vous voulez la main dessus, parce que c'est le domaine qui vous permet de mettre votre propre hébergement ou un proxy devant l'application. En attendant, mettez l'effort sur les constats qu'il vous revient de corriger.
Une Content-Security-Policy peut-elle casser mon application ?
Oui, et c'est le résultat normal d'une première tentative. Une politique qui n'autorise pas les scripts en ligne arrêtera les scripts en ligne, y compris ceux générés par votre builder, et la page reste blanche ou perd une fonction, avec une erreur visible seulement dans la console du navigateur. Commencez par Content-Security-Policy-Report-Only, qui signale ce qu'elle aurait bloqué sans rien bloquer, et lisez les rapports pendant une semaine avant de l'activer pour de bon.
Les en-têtes de sécurité aident-ils si ma base de données est lisible par n’importe qui ?
Non. Les en-têtes sont des instructions aux navigateurs qui visitent votre site, et celui qui lit votre base de données directement n'utilise pas de navigateur et ne visite pas votre site. Cette requête part droit vers votre fournisseur de base de données et ne touche jamais vos pages, donc aucun en-tête posé dessus ne s'y applique. C'est Row Level Security qui décide de celle-là.