En-têtes de sécurité
Les en-têtes que PostShip attend sur votre page d'accueil, le contenu mixte, et ce qui fait échouer le contrôle.
Mis à jour le 11 septembre 2026
Sur cette page
- Ce que PostShip vérifie
- Les manques (le contrôle échoue)
- Les avertissements (le contrôle passe)
- Le score
- Régler
- Ce qui déclenche une alerte
- Limites et plans
- Dépannage
- Pourquoi le contrôle passe-t-il alors que ma CSP est absente ?
- Pourquoi « hsts_absent » n'apparaît-il pas sur mon site en http ?
- Pourquoi le contenu mixte cite-t-il une image que j'ai déjà remplacée ?
Ce que ce contrôle attrape n'a pas de symptôme : le site répond 200, s'affiche, et reste encadrable dans une iframe de phishing, ou charge un script en http:// qu'un réseau d'hôtel peut remplacer. Rien ne casse jusqu'au jour où quelqu'un s'en sert. PostShip lit les en-têtes que votre serveur envoie sur la page d'accueil, et le HTML qu'elle contient, à chaque déploiement.
Ce que PostShip vérifie
Une seule requête, celle de la page d'accueil du projet. Les en-têtes jugés sont ceux de la réponse finale, après redirections : c'est elle que le navigateur affiche, et une redirection 301 sans HSTS avant une page qui l'a n'est pas le défaut qu'on cherche. Pas de navigateur : on lit ce que le serveur envoie, pas ce que le JavaScript ajoute ensuite.
Deux niveaux, tenus séparés d'un bout à l'autre. Les manques sont des protections dont l'absence ouvre une attaque connue et documentée : ils font échouer le contrôle. Les avertissements sont des durcissements qu'un site sérieux devrait avoir, mais dont l'absence est la norme sur la moitié du web ; en faire un échec vous réveillerait toutes les nuits pour rien.
Les manques (le contrôle échoue)
| Code | Ce qui manque |
|---|---|
hsts_absent | Pas d'en-tête Strict-Transport-Security : un visiteur peut être renvoyé en http à son insu. Vérifié seulement en https — les navigateurs ignorent l'en-tête reçu en clair. |
x_content_type_absent | Pas de X-Content-Type-Options: nosniff — le navigateur peut exécuter un fichier comme s'il était d'un autre type. Seule la valeur nosniff compte ; none ou une faute de frappe vaut absence. |
frame_protection_absente | Ni X-Frame-Options, ni directive frame-ancestors dans la CSP : le clickjacking est possible. L'un ou l'autre suffit. |
contenu_mixte | La page en https charge des ressources en http : le navigateur les bloque ou avertit. |
Le contenu mixte ne compte que les éléments que le navigateur charge lui-même : script, iframe, img, et les link en rel="stylesheet". Un lien a href="http://…" est une navigation choisie par le visiteur, pas une ressource de la page. La liste est dédoublonnée et plafonnée à 10 : au-delà, le problème est systémique.
Les avertissements (le contrôle passe)
| Code | Ce qui est signalé |
|---|---|
csp_absente | Pas de Content-Security-Policy. |
referrer_policy_absente | Pas de Referrer-Policy. |
permissions_policy_absente | Pas de Permissions-Policy. |
serveur_bavard | Le serveur annonce sa version dans Server ou X-Powered-By (nginx/1.18.0). Server: nginx seul ne dit rien d'utile à un attaquant ; avec le numéro, c'est la liste des CVE à essayer. |
Le score
100 points, moins 20 par manque et 5 par avertissement. Tout manquer donne exactement 0. Le score et la valeur brute de chaque en-tête sont dans le détail du contrôle, pour que vous voyiez ce que votre serveur envoie réellement plutôt que notre lecture.
Régler
Rien à configurer : la cible est créée par PostShip pour chaque projet, sur l'URL de base, et ne consomme pas votre quota d'URLs. Projet → Santé → Contrôles du site → Sécurité pour lire le dernier verdict, le score, et les en-têtes reçus. Le contrôle peut être désactivé depuis la même carte si vous ne voulez pas le voir.
Comme les autres contrôles du site, il tourne au déploiement (webhook, T+2 / T+8, « Lancer maintenant »), jamais au tick ordinaire : les en-têtes d'un site ne changent qu'au déploiement.
Ce qui déclenche une alerte
Un fail, c'est-à-dire au moins un manque, après le nombre de confirmations de vos règles. L'alerte porte la phrase du code (par exemple « Rien n'empêche d'afficher le site dans une iframe (ni X-Frame-Options, ni frame-ancestors) : le clickjacking est possible. »). Les avertissements ne sonnent jamais : ils se lisent dans l'app.
Pas de réponse (délai, DNS, TLS illisible) : le contrôle est en error, pas en fail. Une coupure réseau n'est pas un défaut de sécurité, et le contrôle HTTP la signale déjà.
Un échec pèse aussi sur le Ship Score, dans la catégorie « hygiène du site » (10 points, plafonnés pour l'ensemble des contrôles).
Limites et plans
| Free | Pro | Team | |
|---|---|---|---|
| Verdict et score à l'écran | Oui | Oui | Oui |
| Alerte sur un manque | Non | Oui | Oui |
Free voit le résultat sur la page Santé ; ce sont les notifications des contrôles de déploiement que le plan ne porte pas. Voir les plans.
Dépannage
Pourquoi le contrôle passe-t-il alors que ma CSP est absente ?
Parce que l'absence de CSP est un avertissement, pas un manque : une CSP mal écrite casse un site, et exiger qu'elle existe pousserait à en poser une vide. Le panneau Scripts tiers propose une directive script-src construite sur ce que PostShip a réellement vu.
Pourquoi « hsts_absent » n'apparaît-il pas sur mon site en http ?
HSTS n'a de sens qu'en https. Reprocher son absence à une page http accuserait le mauvais problème : c'est le http lui-même qu'il faut signaler, et le contrôle des redirections le fait (base_en_http).
Pourquoi le contenu mixte cite-t-il une image que j'ai déjà remplacée ?
Le contrôle tourne au déploiement. Si l'image a été remplacée sans déploiement (un CMS, par exemple), relancez la cible avec « Lancer maintenant » ou attendez le prochain ship.