Aller au contenu principal

Ajouter des en-têtes HTTP

Ce guide vous montrera comment ajouter des en-têtes HTTP à votre site WordPress.com pour gérer différentes requêtes et réponses.

À propos des en-têtes HTTP

Les en-têtes HTTP transmettent des informations supplémentaires avec une requête ou une réponse HTTP sur votre site. Les en-têtes HTTP indiquent à votre site comment traiter certaines requêtes et collecter des informations, en fonction de la source, du service ou du réseau social d’où provient le code d’en-tête.

La plupart des en-têtes HTTP sont optimisés sur WordPress.com et ne nécessitent aucune modification, mais beaucoup peuvent également être appliqués ou modifiés sur votre site si vous en avez besoin. Gardez à l’esprit que certains codes d’en-tête HTTP ne sont pas modifiables sur WordPress.com s’ils présentent une menace de sécurité ou s’ils entrent en conflit avec d’autres fonctions de la plateforme WordPress.com.

Liste des en-têtes HTTP courants

Vous trouverez ci-dessous un tableau présentant les en-têtes HTTP courants pouvant être appliqués à votre site, avec des notes indiquant quels en-têtes HTTP ne peuvent pas être modifiés sur WordPress.com. Vous pouvez également en apprendre davantage sur les différents en-têtes HTTP sur MDN.

En-têteDescription
X-Robots-TagIndique comment une page web sera indexée dans les résultats des moteurs de recherche publics. L’en-tête HTTP est effectivement équivalent à <meta name="robots" content="...">.
Access-Control-Allow-HeadersUtilisé en réponse à une requête de pré-vérification (preflight), qui inclut les Access-Control-Request-Headers pour indiquer quels en-têtes HTTP peuvent être utilisés lors de la requête réelle.
Access-Control-Allow-MethodsSpécifie une ou plusieurs méthodes autorisées lors de l’accès à une ressource en réponse à une requête de pré-vérification.
Access-Control-Allow-CredentialsIndique aux navigateurs s’il faut exposer la réponse au code JavaScript côté client lorsque le mode d’identification de la requête (Request.credentials) est include.
Access-Control-Allow-OriginIndique si la réponse peut être partagée avec le code demandeur provenant de l’origine donnée.
Access-Control-Expose-HeadersPermet à un serveur d’indiquer quels en-têtes de réponse doivent être rendus disponibles aux scripts exécutés dans le navigateur en réponse à une requête cross-origin.
X-Frame-OptionsIndique si un navigateur doit être autorisé ou non à afficher une page dans un <frame>, <iframe>, <embed> ou <object>. Les sites peuvent utiliser cet en-tête pour éviter les attaques de type click-jacking, en s’assurant que leur contenu n’est pas intégré dans d’autres sites.
X-XSS-ProtectionUne fonctionnalité d’Internet Explorer, Chrome et Safari qui empêche le chargement des pages lorsqu’elles détectent des attaques par script intersite (XSS) réfléchies. Ces protections sont largement inutiles dans les navigateurs modernes lorsque les sites implémentent une Content-Security-Policy stricte qui désactive l’utilisation du JavaScript en ligne (‘unsafe-inline’).
X-Content-Type-OptionsIndique que les types MIME annoncés dans les en-têtes Content-Type doivent être respectés et ne pas être modifiés. Cet en-tête HTTP vous permet d’éviter le reniflage de type MIME en indiquant que les types MIME sont délibérément configurés.
Strict-Transport-SecurityInforme les navigateurs que le site ne doit être accessible qu’en utilisant HTTPS et que toute tentative future d’y accéder en HTTP doit être automatiquement convertie en HTTPS.
Remarque : Contactez le support pour ajouter les directives includeSubdomains et preload.
Referrer-PolicyContrôle la quantité d’informations de référent (envoyées avec l’en-tête Referer) à inclure dans les requêtes. En plus de l’en-tête HTTP, vous pouvez définir cette politique en HTML.
Content-Security-PolicyPermet aux administrateurs de sites de contrôler les ressources que l’agent utilisateur peut charger pour une page donnée. À quelques exceptions près, les politiques consistent principalement à spécifier les origines des serveurs et les points de terminaison des scripts. Cela aide à se protéger contre les attaques par script intersite.

Cet en-tête peut être modifié avec une extension comme Redirection ou en utilisant custom-redirects.php.

Ajouter des en-têtes HTTP à un site

Il existe deux méthodes pour ajouter un en-tête de réponse HTTP à votre site.

Ajouter des en-têtes HTTP avec une extension de redirection

Bien qu’il existe plusieurs façons d’ajouter des en-têtes HTTP à un site compatible avec les extensions, notre meilleure recommandation est d’utiliser l’extension Redirection.

Bien que le nom de l’extension Redirection suggère qu’elle est uniquement destinée aux redirections, vous pouvez utiliser cette extension en toute sécurité pour appliquer des en-têtes HTTP sans utiliser de redirections du tout. Si vous choisissez de n’appliquer que des en-têtes HTTP, vos pages ne seront affectées par aucune redirection.

Après avoir installé l’extension Redirection, vous pouvez suivre les étapes suivantes pour ajouter un en-tête HTTP :

  1. Accédez aux réglages de l’extension en naviguant vers Outils → Redirection.
  2. Cliquez sur l’onglet « Site ».
  3. Faites défiler vers le bas jusqu’à la section « En-têtes HTTP » en bas de l’écran. Vous y trouverez un tableau affichant une ligne pour chaque en-tête HTTP de votre site.
  4. Cliquez sur le bouton « Ajouter un en-tête » pour ajouter une ligne au tableau pour un autre en-tête HTTP.
  5. Choisissez les informations suivantes :
    • Emplacement : Où cet en-tête HTTP doit-il s’appliquer ? En général, site est l’option correcte pour la plupart des en-têtes HTTP.
    • En-tête : Cliquer sur cette option affiche un menu déroulant des en-têtes HTTP courants.
      • Si l’option que vous souhaitez utiliser n’est pas disponible, vous pouvez également ajouter un en-tête personnalisé, ce qui ouvrira une nouvelle zone pour saisir l’en-tête HTTP personnalisé et sa valeur.
      • Même si une option apparaît dans la liste déroulante, elle peut ne pas être disponible sur la plateforme WordPress.com comme expliqué ci-dessus.
    • Valeur : Cela affichera les options disponibles pour un en-tête HTTP donné. Cependant, dans le cas d’en-têtes personnalisés, cela peut apparaître comme un champ vide à compléter.
  6. Cliquez sur le bouton « Mettre à jour », et les en-têtes HTTP seront ajoutés aux requêtes et réponses de votre site web.

Il peut s’écouler un certain temps avant que les modifications des en-têtes HTTP ne s’appliquent à votre site en ligne. Bien que les modifications finissent par se mettre à jour avec le temps, vous pouvez également envisager de vider le cache de votre navigateur et de vider le cache de votre site web.

Ajouter des en-têtes HTTP avec du code PHP

Si vous recherchez une solution plus avancée ou si vous souhaitez éviter l’utilisation d’extensions, vous pouvez également définir des en-têtes HTTP via un fichier custom-redirects.php en utilisant la fonction PHP header(). Celui-ci peut être ajouté au dossier racine du site en utilisant SFTP.

Toute modification via SFTP est considérée comme une personnalisation avancée du site. Vous ne devez pas modifier de fichiers à moins de savoir exactement ce que le changement va produire, et nous vous conseillons de n’utiliser cette méthode que si vous êtes à l’aise avec l’utilisation de SFTP.

Voici un aperçu général de la manière d’ajouter des en-têtes HTTP aux fichiers de votre site en utilisant SFTP :

  1. Connectez-vous à votre site WordPress à l’aide de votre client SFTP préféré.
  2. Par défaut, vous devriez vous trouver dans le dossier racine. Vérifiez que vous êtes dans le dossier htdocs (racine) pour les sites WordPress.com. Dans ce dossier, créez un nouveau fichier appelé custom-redirects.php
  3. Utilisez un éditeur de texte sur votre appareil (tel que TextEdit ou Notepad) pour modifier le fichier selon vos besoins.
  4. Enregistrez le fichier sur le serveur.

Un exemple de fichier custom-redirects.php valide est présenté ci-dessous :

<?php
header('X-XSS-Protection: 1; mode=block');
header('X-Content-Type-Options: nosniff');
header('X-Frame-Options: SAMEORIGIN');
header('Referrer-Policy: no-referrer-when-downgrade');
<?php header(‘X-XSS-Protection: 1; mode=block’); header(‘X-Content-Type-Options: nosniff’); header(‘X-Frame-Options: SAMEORIGIN’); header(‘Referrer-Policy: no-referrer-when-downgrade’);

Dernière mise à jour : juillet 03, 2026