Comment configurer les en-têtes de sécurité dans Nginx

Dernière mise à jour le 25 juillet 2024 à 15h28 par Joshua James
Temps de lecture estimé : 16 minutes
Configuration des en-têtes de sécurité dans Nginx

La configuration des en-têtes de sécurité dans NGINX est essentielle pour améliorer la sécurité de vos applications Web. Les en-têtes de sécurité protègent contre diverses attaques, telles que le cross-site scripting (XSS), le détournement de clics et d'autres attaques par injection de code. Ils indiquent au navigateur comment gérer le contenu de votre site, offrant ainsi une couche de sécurité supplémentaire.

Ce guide vous guidera à travers les étapes de configuration des en-têtes de sécurité dans NGINX, vous aidant à protéger vos applications Web et à améliorer la sécurité globale.

Implémentation de HTTP Strict Transport Security (HSTS) dans NGINX

Comprendre le HSTS

HTTP Strict Transport Security (HSTS) est un protocole de sécurité de site Web crucial. Il impose que les connexions à un domaine se fassent exclusivement via HTTPS. Cela atténue les risques tels que les attaques de l'homme du milieu et garantit l'intégrité et la confidentialité des données transmises en ligne. Lorsqu'un utilisateur tente d'accéder à un site via HTTP, HSTS met automatiquement à niveau la connexion vers HTTPS.

Configuration de HSTS dans NGINX

Pour configurer HSTS dans NGINX, vous devez mettre à jour le bloc serveur dans le fichier de configuration NGINX. Ce fichier réside généralement dans /etc/nginx/nginx.conf ou dans les configurations spécifiques au site dans /etc/nginx/sites-available/. La mise à jour implique l'ajout d'un en-tête indiquant au navigateur de toujours utiliser HTTPS pour le domaine spécifié.

Dans le bloc serveur de votre domaine, ajoutez la ligne suivante :

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";

Cette ligne contient deux composants :

  • max-age=31536000 : demandez au navigateur de ne pas oublier d'utiliser HTTPS pour votre site au cours des 12 prochains mois.
  • includeSubDomains : applique la politique HSTS à tous les sous-domaines de votre site pour une sécurité complète.

Exemple de configuration NGINX avec HSTS

Votre configuration NGINX avec l'en-tête HSTS pourrait ressembler à ceci :

upstream my_portal {
    server 127.0.0.1:8080;
}

server {
    listen 80;
    server_name example.com;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";

    location / {
        proxy_pass http://my_portal;
    }
}

Après avoir ajouté cet en-tête, rechargez NGINX pour appliquer les modifications avec sudo systemctl reload nginx ou sudo nginx -s reload.

Exemples de configuration NGINX supplémentaires

Pour différents scénarios, votre configuration NGINX avec HSTS peut varier. Voici des exemples supplémentaires :

Serveur multi-domaine

server {
    listen 80;
    server_name example1.com example2.com;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";

    location / {
        # Configuration details
    }
}

Cette configuration applique HSTS à plusieurs domaines hébergés sur le même serveur. Chaque domaine répertorié appliquera les connexions HTTPS.

Serveur avec terminaison SSL

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate /path/to/certificate;
    ssl_certificate_key /path/to/private/key;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";

    location / {
        # Configuration details
    }
}

Cette configuration est destinée aux serveurs gérant la terminaison SSL. Il configure HSTS sur un port sécurisé (443) avec des certificats SSL spécifiés, renforçant les connexions sécurisées.

Configuration de la politique de sécurité du contenu (CSP) dans NGINX

Implémentation de CSP dans NGINX

L'intégration d'une politique de sécurité du contenu (CSP) dans NGINX est une démarche stratégique pour améliorer la sécurité des applications Web. Cela implique l'ajout d'un en-tête spécifique au sein du bloc serveur de votre fichier de configuration NGINX. Généralement trouvé dans /etc/nginx/nginx.conf ou dans le répertoire /etc/nginx/sites-available/, ce fichier nécessite une édition minutieuse pour appliquer efficacement CSP.

Pour une configuration CSP fondamentale, ajoutez la ligne suivante dans le bloc serveur :

add_header Content-Security-Policy "default-src 'self';" always;

Cette directive restreint le chargement du contenu au domaine du site Web (« soi »), réduisant considérablement le risque d'exécution de contenu externe malveillant.

Exemple de configuration NGINX avec CSP

Votre configuration NGINX avec la directive CSP de base pourrait ressembler à ceci :

upstream my_portal {
    server 127.0.0.1:8080;
}

server {
    listen 80;
    server_name example.com;
    add_header Content-Security-Policy "default-src 'self';" always;

    location / {
        proxy_pass http://my_portal;
    }
}

Rechargez NGINX avec sudo systemctl reload nginx ou sudo nginx -s reload après avoir ajouté cette directive.

Personnalisation du CSP pour des besoins spécifiques

CSP peut être personnalisé pour répondre aux besoins de sécurité spécifiques de votre site Web. Voici des configurations étendues pour différents scénarios :

Autoriser les images de n'importe quelle source

add_header Content-Security-Policy "default-src 'self'; img-src *;" always;

Cette configuration permet de charger des images depuis n'importe quelle source, en maintenant un contrôle strict sur les autres types de contenu.

Configuration de scripts et de styles spécifiques

add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://trustedscript.com; style-src 'self' 'unsafe-inline';";

Ce paramètre autorise les scripts de votre domaine et d'une source externe fiable ainsi que les styles en ligne, équilibrant ainsi fonctionnalité et sécurité.

Explorer les directives et les options du CSP

Directives dans CSP

Les directives CSP sont des règles qui définissent la politique pour des types de contenu spécifiques. Les directives courantes comprennent :

  • default-src : la stratégie par défaut appliquée à la plupart des types de contenu.
  • script-src : régit les sources des ressources JavaScript.
  • style-src : spécifie les sources autorisées pour les ressources CSS.
  • img-src : contrôle les sources des ressources d'image.
  • connect-src : définit les politiques pour les connexions réseau telles que XMLHttpRequest, WebSocket et EventSource.

Expressions sources dans CSP

Les expressions source définissent les sources autorisées pour chaque directive :

  • « aucun » : bloque toutes les sources.
  • « soi » : autorise les ressources de la même origine.
  • « unsafe-inline » : autorise les ressources en ligne telles que les styles ou les URL JavaScript.
  • 'unsafe-eval' : autorise JavaScript eval() fonctions et méthodes similaires.
  • https : Active les ressources à partir de n'importe quelle URL HTTPS.

Configuration de la protection X-XSS dans NGINX

Introduction à la protection X-XSS

X-XSS-Protection, ou l'en-tête Cross-Site Scripting, est essentiel pour protéger les applications Web contre les attaques XSS (Cross-Site Scripting). Pris en charge par les principaux navigateurs Web tels que Chrome, Internet Explorer et Safari, cet en-tête améliore la sécurité Web en empêchant le chargement de pages lorsque des attaques XSS réfléchies sont détectées.

Activation de la protection X-XSS dans NGINX

L'intégration de l'en-tête X-XSS-Protection dans la configuration de votre serveur NGINX renforce la protection XSS native du navigateur. Pour activer cette fonctionnalité de sécurité, accédez à votre fichier de configuration NGINX, généralement situé dans /etc/nginx/nginx.conf ou dans le répertoire /etc/nginx/sites-available/.

Dans le bloc serveur de votre fichier de configuration NGINX, insérez cette directive :

add_header X-XSS-Protection "1; mode=block";

Cette directive comprend deux parties :

  • 1 : Active le filtre XSS du navigateur.
  • mode=block : demande au navigateur de bloquer la page si une attaque XSS est détectée, plutôt que d'essayer de la nettoyer.

Exemple de configuration NGINX avec protection X-XSS

Un exemple de configuration NGINX incluant X-XSS-Protection peut apparaître comme suit :

upstream my_portal {
    server 127.0.0.1:8080;
}

server {
    listen 80;
    server_name example.com;
    add_header X-XSS-Protection "1; mode=block";

    location / {
        proxy_pass http://my_portal;
    }
}

Après avoir ajouté cet en-tête, rechargez NGINX en utilisant soit sudo systemctl reload nginx, soit sudo nginx -s reload.

Scénarios de configuration NGINX supplémentaires

Pour un serveur avec SSL

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate /path/to/certificate;
    ssl_certificate_key /path/to/private/key;
    add_header X-XSS-Protection "1; mode=block";

    # Further configuration
}

Cette configuration est destinée aux serveurs avec SSL, garantissant que X-XSS-Protection est active sur les connexions cryptées.

Gestion de plusieurs domaines

server {
    listen 80;
    server_name example1.com example2.com;
    add_header X-XSS-Protection "1; mode=block";

    # Further configuration
}

Cette configuration applique la protection X-XSS sur plusieurs domaines hébergés sur un seul serveur.

Configuration des options X-Frame dans NGINX

Le rôle des options X-Frame

X-Frame-Options est un en-tête de sécurité essentiel conçu pour protéger les sites Web contre les attaques de détournement de clic. Il empêche les pages Web d'être affichées dans des frames ou des iframes, qui sont souvent utilisés dans ces attaques. Pris en charge par tous les principaux navigateurs Web, X-Frame-Options offre une protection étendue, améliorant la sécurité de votre présence Web sur différentes plates-formes.

Implémentation des options X-Frame dans NGINX

L'intégration de l'en-tête X-Frame-Options dans la configuration de votre serveur NGINX est cruciale pour améliorer la sécurité de votre site. Cette tâche implique la modification du fichier de configuration NGINX, généralement trouvé dans /etc/nginx/nginx.conf ou dans le répertoire /etc/nginx/sites-available/.

Pour activer cette fonctionnalité de sécurité, ajoutez la directive suivante au bloc serveur dans votre fichier de configuration NGINX :

add_header X-Frame-Options "DENY";

Cette directive, définie sur « DENY », demande au navigateur de bloquer toute tentative d'affichage de la page dans un cadre ou une iframe, offrant ainsi une défense robuste contre le détournement de clic.

Exemple de configuration NGINX avec options X-Frame

Un exemple de configuration NGINX avec l'en-tête X-Frame-Options est le suivant :

upstream my_portal {
    server 127.0.0.1:8080;
}

server {
    listen 80;
    server_name example.com;
    add_header X-Frame-Options "DENY";

    location / {
        proxy_pass http://my_portal;
    }
}

Une fois que vous avez ajouté cet en-tête, il est important de recharger NGINX pour activer les modifications. Cela peut être fait en utilisant sudo systemctl reload nginx ou sudo nginx -s reload.

Extension de la configuration NGINX pour les options X-Frame

Pour les serveurs compatibles SSL

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate /path/to/certificate;
    ssl_certificate_key /path/to/private/key;
    add_header X-Frame-Options "DENY";

    # Additional configuration
}

Cette configuration est destinée aux serveurs avec SSL, garantissant que X-Frame-Options est appliqué sur les connexions sécurisées.

Gestion de plusieurs domaines

server {
    listen 80;
    server_name example1.com example2.com;
    add_header X-Frame-Options "DENY";

    # Additional configuration
}

Cette configuration applique l'en-tête X-Frame-Options sur plusieurs domaines sur le même serveur, renforçant ainsi la sécurité de chaque domaine.

Implémentation des options X-Content-Type dans NGINX

Rôle des options X-Content-Type

X-Content-Type-Options est un en-tête de sécurité essentiel dans la sécurité Web qui empêche les navigateurs de détecter le type MIME. Cet en-tête renforce le fait que les navigateurs respectent le type de contenu déclaré dans les en-têtes HTTP, corrigeant les vulnérabilités de sécurité qui peuvent survenir lorsque les navigateurs interprètent mal les types de fichiers, par exemple en traitant les fichiers image comme du HTML exécutable, ce qui pourrait conduire à des attaques de script intersite (XSS).

Configuration des options X-Content-Type dans NGINX

Pour améliorer la sécurité de votre serveur Web avec l'en-tête X-Content-Type-Options, vous devez modifier directement le fichier de configuration NGINX. Ce fichier se trouve généralement dans /etc/nginx/nginx.conf ou dans les configurations spécifiques au site dans /etc/nginx/sites-available/.

Incorporez cet en-tête en ajoutant la ligne suivante au server bloc de votre configuration NGINX :

add_header X-Content-Type-Options "nosniff";

Le paramètre « nosniff » indique au navigateur de suivre strictement le type de contenu spécifié par le serveur, empêchant ainsi toute interprétation alternative du contenu.

Exemple de configuration NGINX avec X-Content-Type-Options

Une configuration NGINX avec X-Content-Type-Options peut être structurée comme suit :

upstream my_portal {
    server 127.0.0.1:8080;
}

server {
    listen 80;
    server_name example.com;
    add_header X-Content-Type-Options "nosniff";

    location / {
        proxy_pass http://my_portal;
    }
}

Après avoir mis à jour votre configuration, assurez-vous de recharger NGINX pour que les modifications prennent effet, en utilisant sudo systemctl reload nginx ou sudo nginx -s reload.

Exemples de configuration NGINX étendus

Configuration pour SSL/TLS

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate /path/to/certificate.pem;
    ssl_certificate_key /path/to/key.pem;
    add_header X-Content-Type-Options "nosniff";

    # Additional SSL configurations and locations
}

Cette configuration est destinée aux serveurs avec SSL/TLS, appliquant X-Content-Type-Options sur des connexions sécurisées pour améliorer la sécurité.

Configuration du serveur multi-domaine

server {
    listen 80;
    server_name example1.com example2.com;
    add_header X-Content-Type-Options "nosniff";

    # Additional configurations for multiple domains
}

Cette configuration applique l'en-tête X-Content-Type-Options sur plusieurs domaines hébergés sur le même serveur, garantissant des paramètres de sécurité cohérents sur tous les domaines.

Configuration de la politique de référence dans NGINX

La fonction de la politique de référence

Referrer-Policy est un en-tête HTTP essentiel pour améliorer la confidentialité et la sécurité des utilisateurs sur le Web. Il contrôle la quantité d'informations de référence incluses dans l'en-tête Referer lorsque les utilisateurs naviguent de votre site vers d'autres, protégeant ainsi les informations sensibles de l'exposition dans les requêtes Web.

Configuration de la politique de référence dans NGINX

Pour implémenter l'en-tête Referrer-Policy dans votre serveur NGINX, modifiez le fichier de configuration NGINX, généralement trouvé dans /etc/nginx/nginx.conf ou dans le répertoire /etc/nginx/sites-available/. Ajoutez la directive suivante au bloc serveur :

add_header Referrer-Policy "no-referrer";

Cette directive, définie sur « no-referrer », garantit qu'aucune information de référence n'est envoyée pendant la navigation sur le site, maximisant ainsi la confidentialité.

Exemple de configuration NGINX avec Referrer-Policy

Votre configuration NGINX avec l'en-tête Referrer-Policy pourrait ressembler à ceci :

upstream my_portal {
    server 127.0.0.1:8080;
}

server {
    listen 80;
    server_name example.com;
    add_header Referrer-Policy "no-referrer";

    location / {
        proxy_pass http://my_portal;
    }
}

Après avoir ajouté cet en-tête, rechargez NGINX avec des commandes comme sudo systemctl reload nginx ou sudo nginx -s reload.

Options et définitions de la politique de référence

  • no-referrer : aucune information de référence n'est envoyée.
  • no-referrer-when-downgrade (par défaut) : envoie des informations de référence pour les destinations de même origine ou pour les URL de destination sécurisées (HTTPS) à partir d'une page sécurisée.
  • origin : envoie uniquement l'origine (schéma, hôte et port).
  • origin-when-cross-origin : envoie l'URL complète pour les demandes de même origine mais uniquement l'origine pour les autres cas.
  • same-origin : envoie un référent complet pour les requêtes de même origine mais aucun en-tête pour les requêtes d'origine croisée.
  • strict-origin : envoie l'origine des requêtes HTTPS mais aucun en-tête pour les requêtes HTTP.
  • strict-origin-when-cross-origin : envoie un référent complet aux requêtes de même origine, l'origine aux destinations HTTPS à partir des pages HTTPS et aucun en-tête aux destinations HTTP.
  • unsafe-url : envoie l'URL complète quelle que soit l'origine ou la sécurité (non recommandé).

Exemples de configuration NGINX étendus

Configuration SSL/TLS

server {
    listen 443 ssl;
    server_name secure.example.com;
    ssl_certificate /path/to/certificate.pem;
    ssl_certificate_key /path/to/key.pem;
    add_header Referrer-Policy "no-referrer";

    # Additional SSL configurations
}

Cette configuration applique l'en-tête Referrer-Policy dans un environnement sécurisé compatible SSL/TLS, améliorant ainsi la confidentialité sur les connexions cryptées.

Configuration du serveur multi-domaine

server {
    listen 80;
    server_name example1.com example2.com;
    add_header Referrer-Policy "no-referrer";

    # Additional configurations for each domain
}

Cette configuration garantit que l'en-tête Referrer-Policy est appliqué sur plusieurs domaines hébergés sur le même serveur, en conservant des paramètres de confidentialité cohérents.

Implémentation de la politique d'autorisations dans NGINX

Comprendre la politique des autorisations

L'en-tête Permissions-Policy permet aux administrateurs Web de contrôler précisément les fonctionnalités du navigateur et les API de leurs sites Web. La configuration de cet en-tête renforce considérablement la sécurité et la confidentialité du site, en permettant des restrictions de fonctionnalités telles que la géolocalisation, la caméra et le microphone en fonction des besoins spécifiques de votre site.

Configuration de la politique d'autorisations dans NGINX

Pour incorporer l'en-tête Permissions-Policy dans votre serveur NGINX, modifiez le fichier de configuration NGINX, généralement situé dans /etc/nginx/nginx.conf ou dans le répertoire /etc/nginx/sites-available/.

Ajoutez la directive suivante au bloc serveur :

add_header Permissions-Policy "geolocation=(); midi=(); notifications=(); push=(); sync-xhr=(); accelerometer=(); gyroscope=(); magnetometer=(); payment=(); usb=(); vr=(); camera=(); microphone=(); speaker=(); vibrate=(); ambient-light-sensor=(); autoplay=(); encrypted-media=(); execute-clipboard=(); document-domain=(); fullscreen=(); imagecapture=(); lazyload=(); legacy-image-formats=(); oversized-images=(); unoptimized-lossy-images=(); unoptimized-lossless-images=(); unsized-media=(); vertical-scroll=(); web-share=(); xr-spatial-tracking=();";

Cette directive répertorie diverses fonctionnalités et API du navigateur, en les définissant toutes sur (), ce qui les désactive efficacement. Cette configuration fournit une approche globale pour limiter les fonctionnalités susceptibles de compromettre la confidentialité ou la sécurité des utilisateurs.

Exemple de configuration NGINX avec politique d'autorisations

Voici un exemple de ce à quoi pourrait ressembler votre configuration NGINX avec l'en-tête Permissions-Policy :

upstream my_portal {
    server 127.0.0.1:8080;
}

server {
    listen 80;
    server_name example.com;
    add_header Permissions-Policy "geolocation=(); midi=(); notifications=(); push=(); sync-xhr=(); accelerometer=(); gyroscope=(); magnetometer=(); payment=(); usb=(); vr=(); camera=(); microphone=(); speaker=(); vibrate=(); ambient-light-sensor=(); autoplay=(); encrypted-media=(); execute-clipboard=(); document-domain=(); fullscreen=(); imagecapture=(); lazyload=(); legacy-image-formats=(); oversized-images=(); unoptimized-lossy-images=(); unoptimized-lossless-images=(); unsized-media=(); vertical-scroll=(); web-share=(); xr-spatial-tracking=();";

    location / {
        proxy_pass http://my_portal;
    }
}

Cette directive répertorie de manière exhaustive diverses fonctionnalités et API du navigateur, en les définissant sur () pour les désactiver efficacement.

Exemple de configuration NGINX avec politique d'autorisations

Votre configuration NGINX, y compris la politique d'autorisations, peut ressembler à ceci :

upstream my_portal {
    server 127.0.0.1:8080;
}

server {
    listen 80;
    server_name example.com;
    add_header Permissions-Policy "geolocation=(); midi=(); notifications=(); push=(); sync-xhr=(); accelerometer=(); gyroscope=(); magnetometer=(); payment=(); usb=(); vr=(); camera=(); microphone=(); speaker=(); vibrate=(); ambient-light-sensor=(); autoplay=(); encrypted-media=(); execute-clipboard=(); document-domain=(); fullscreen=(); imagecapture=(); lazyload=(); legacy-image-formats=(); oversized-images=(); unoptimized-lossy-images=(); unoptimized-lossless-images=(); unsized-media=(); vertical-scroll=(); web-share=(); xr-spatial-tracking=();";

    location / {
        proxy_pass http://my_portal;
    }
}

Rechargez NGINX avec sudo systemctl reload nginx ou sudo nginx -s reload après avoir effectué ces modifications.

Explication des options de politique d'autorisations

L'en-tête Permissions-Policy vous permet de personnaliser l'utilisation de diverses fonctionnalités :

  • géolocalisation: Contrôle l'accès aux données de géolocalisation.
  • midi: Gère l'accès aux appareils MIDI.
  • avis: Gère l'affichage des notifications.
  • pousser: Affecte la fonctionnalité de notification push.
  • synchronisation-xhr: concerne la requête XMLHTTPRequest synchrone.
  • accéléromètre: Dicte l’accès à l’accéléromètre de l’appareil.
  • gyroscope: Contrôle l'accès au gyroscope.
  • magnétomètre: Gère l'accès au magnétomètre de l'appareil.
  • paiement: S'applique aux fonctionnalités de demande de paiement.
  • USB: Régit l’accès aux périphériques USB.
  • réalité virtuelle: Concerne les fonctionnalités de réalité virtuelle.
  • caméra: Gère l'accès à la caméra.
  • microphone: Dicte l’accès au microphone.
  • conférencier: Contrôle l’accès aux haut-parleurs.
  • vibrer: Affecte l'API de vibration.
  • détecteur de lumière ambiante: Concerne le capteur de lumière ambiante.
  • lecture automatique: Contrôle la lecture automatique des médias.
  • médias cryptés: Gère l'accès aux médias cryptés.
  • exécuter-presse-papiers: Régit l’accès en lecture/écriture au presse-papiers.
  • domaine-document: Concerne la fonctionnalité document.domain.
  • plein écran: Dicte l’accès en plein écran.
  • capture d'image: Contrôle la fonctionnalité de capture d’image.
  • chargement paresseux: Affecte le chargement paresseux des images.
  • formats d'image hérités: Concerne les formats d'image existants.
  • images surdimensionnées: Régit le chargement des images surdimensionnées.
  • images avec perte non optimisées: Gère les images avec perte non optimisées.
  • images sans perte non optimisées: Concerne les images sans perte non optimisées.
  • média non dimensionné: Contrôle les médias sans taille explicite.
  • défilement vertical: Affecte le défilement vertical.
  • partage Web: Concerne les fonctionnalités de partage Web.
  • suivi-spatial-xr: Gère le suivi spatial XR.

Configurations avancées de la politique d'autorisations dans NGINX

Configuration de la politique d'autorisations avec des domaines spécifiques et des caractères génériques

Au-delà de la configuration de base de la désactivation des fonctionnalités à l'aide de (), la politique d'autorisations dans NGINX peut être personnalisée pour autoriser certaines fonctionnalités de domaines spécifiques ou à l'aide de caractères génériques. Cette configuration avancée permet un contrôle plus nuancé sur ce à quoi votre site Web peut accéder et d'où.

Exemple : autoriser les fonctionnalités de domaines spécifiques

server {
    listen 80;
    server_name example.com;
    add_header Permissions-Policy "geolocation=(https://trusteddomain.com), microphone=(https://alloweddomain.com)";

    location / {
        proxy_pass http://my_portal;
    }
}

Cette configuration permet l'accès aux données de géolocalisation uniquement depuis https://trusteddomain.com et l'accès au microphone uniquement depuis https://alloweddomain.com, améliorant ainsi la sécurité en limitant ces fonctionnalités sensibles aux sources fiables.

Exemple : utilisation de caractères génériques pour des autorisations étendues

server {
    listen 80;
    server_name example.com;
    add_header Permissions-Policy "camera=*; fullscreen=*";

    location / {
        proxy_pass http://my_portal;
    }
}

Le caractère générique * dans cette configuration permet l'accès à la caméra et le mode plein écran depuis n'importe quel domaine. Cette approche offre des autorisations plus larges, adaptées aux sites Web qui nécessitent un accès étendu aux fonctionnalités à partir de diverses sources.

Exemple : combiner des restrictions et des autorisations

server {
    listen 80;
    server_name example.com;
    add_header Permissions-Policy "accelerometer=(); gyroscope=(self https://example2.com); payment=*";

    location / {
        proxy_pass http://my_portal;
    }
}

Dans cette configuration, l'accès à l'accéléromètre est désactivé, l'accès au gyroscope est autorisé depuis le même domaine et https://example2.com, et les demandes de paiement sont autorisées depuis tous les domaines.

Vérification des en-têtes de sécurité avec la commande Curl dans NGINX

Utiliser Curl pour vérifier les en-têtes de sécurité

La commande curl est un outil précieux pour vérifier la configuration des en-têtes de sécurité sur votre serveur NGINX. Il vous permet d'inspecter les en-têtes de votre site Web et de confirmer que les en-têtes de sécurité sont correctement configurés. Cette étape de vérification est cruciale pour garantir que les mesures de sécurité de votre serveur Web sont actives et fonctionnent comme prévu.

Exécution de la commande Curl pour la vérification de l'en-tête

Pour vérifier les en-têtes de votre site Web, exécutez la commande suivante dans votre terminal :

curl -I http://example.com

Remplacez exemple.com par votre nom de domaine. Cette commande demande les en-têtes à votre serveur, fournissant un aperçu des configurations de sécurité actives.

Résultats attendus et interprétation

Lors de l'exécution de la commande curl, vous devriez recevoir un résultat semblable à celui-ci :

HTTP/1.1 200 OK
Server: nginx
Date: Mon, 20 Mar 2023 00:00:00 GMT
Content-Type: text/html
Connection: keep-alive
Strict-Transport-Security: max-age=31536000; includeSubDomains
Content-Security-Policy: default-src 'self';
X-XSS-Protection: 1; mode=block
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Referrer-Policy: no-referrer
Permissions-Policy: geolocation=(); midi=(); notifications=(); push=(); sync-xhr=(); accelerometer=(); gyroscope=(); magnetometer=(); payment=(); usb=(); vr=(); camera=(); microphone=(); speaker=(); vibrate=(); ambient-light-sensor=(); autoplay=(); encrypted-media=(); execute-clipboard=(); document-domain=(); fullscreen=(); imagecapture=(); lazyload=(); legacy-image-formats=(); oversized-images=(); unoptimized-lossy-images=(); unoptimized-lossless-images=(); unsized-media=(); vertical-scroll=(); web-share=(); xr-spatial-tracking=();"

Cette sortie confirme la présence et la configuration correcte de divers en-têtes de sécurité sur votre serveur, tels que Strict-Transport-Security, Content-Security-Policy, X-XSS-Protection et autres. Chaque en-tête répertorié dans le résultat joue un rôle spécifique dans la sécurisation et la protection de votre serveur Web contre diverses vulnérabilités Web.

Conclusion

En configurant les en-têtes de sécurité dans NGINX, vous améliorez considérablement la sécurité de vos applications Web. Examinez et mettez à jour régulièrement vos en-têtes de sécurité pour vous adapter à l'évolution des menaces de sécurité. La mise en œuvre de ces en-têtes permet de vous protéger contre un large éventail d'attaques et garantit une expérience de navigation plus sûre pour vos utilisateurs. Restez vigilant et maintenez votre configuration NGINX à jour pour protéger efficacement vos actifs Web.

Joshua James
Suis-moi
Les derniers articles par Joshua James (tout voir)

Comment installer Android Studio sur Linux Mint 22, 21 ou 20

Comment installer Rust sur Debian 12, 11 ou 10 Linux

Laissez un commentaire


Si vous avez des questions légitimes, telles que des suggestions d'articles, n'hésitez pas à contacter LinuxCapable. Veuillez vous assurer que votre message est rédigé en anglais.

Contactez-nous
À propos de nous Clause de non-responsabilité Politique de confidentialité Termes et conditions