5 directives Nginx pour sécuriser votre serveur web

Il est essentiel de sécuriser son serveur web Nginx lorsqu'il est déployé en Production. En effet, un serveur web Nginx sans ajout de directives de sécurité est très vulnérable.
Dans cet article, nous allons explorer cinq directives Nginx essentielles pour sécuriser votre serveur web.

1. La politique de sécurité de contenu (CSP)

Commençons ce tour d'horizon par le CSP (Content Security Policy).
Il s'agit d'une directive Nginx listant les noms de domaines autorisés à exécuter du JavaScript, charger le CSS, etc...

Voici un exemple de directive CSP :

server {
   ...
   add_header Content-Security-Policy "default-src 'self'; script-src 'self' example.com; style-src 'self'; img-src 'self' example.com";
   ...
}

Dans cet exemple, nous avons ajouté le nom de domaine spécifique example.com pour les directives script-src et img-src. Cela signifie que les scripts et les images peuvent être chargés à partir de votre propre domaine (self) ainsi que du nom de domaine spécifié (example.com), mais pas à partir d'autres sources externes.

La directive default-src 'self' garantit que toutes les autres ressources doivent provenir uniquement de votre propre domaine.

2. HTTP Strict Transport Security (HSTS)

Le HSTS renforce la sécurité de votre serveur web Nginx en garantissant que toutes les communications se font en HTTPS.

Il s'agit d'un header que l'on vient positionner en précisant la durée de mise en cache, l'inclusion des sous-domaines ainsi que le préchargement du site web dans les listes connues des navigateurs.

Voici un exemple de header HSTS :

server {
   ...
   add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload";
   ...
}

3. X-Content-Type

Voici un autre header HTTP assez important, qui renforcera la sécurité de votre serveur web Nginx, selon les sites que vous hébergez dessus.

En effet, la directive X-Content-Type permet de se protéger des attaques du type MIME Sniffing.

Voici un exemple de header X-Content-Type pour Nginx :

server {
   ...
   add_header X-Content-Type-Options nosniff;
   ...
}

Avec la valeur nosniff, le header envoie l'instruction au navigateur web d'utiliser le MIME déclaré dans le header Content-Type. Cela évite tout type d'attaque et d'injections.

4. X-Frame-Options

Comme vous le savez certainement, il existe une balise HTML nommée <iframe>. Cette balise HTML permet de charger une page HTML distante dans la page courante.

C'est donc une balise HTML qui peut s'avérer pratique, mais qui n'est pas sans risque.

Voici un exemple de header X-Frame-Options ayant SAMEORIGIN :

server {
   ...
   add_header X-Frame-Options SAMEORIGIN;
   ...
}

En utilisant la valeur SAMEORIGIN, nous permettons à la page de s'afficher dans une frame si elle provient du même site (même origine). Cela protège contre les attaques de clickjacking en empêchant le chargement de la page dans des frames provenant d'autres sites.

Attention donc à utiliser ce header Nginx uniquement lorsque votre site ne fait pas appel à des balises HTML <iframe> !

5. Les liens sécurisés avec secure_link

Il est parfois très pratique de générer des liens sécurisés. Que ce soit en interne lors d'une redirection, ou encore au déclenchement d'une action.

La directive Nginx secure_link permet de générer des liens sécurisés (signed URLs) pour restreindre l'accès à des ressources spécifiques sur votre serveur. Elle est souvent utilisée pour protéger des téléchargements ou des ressources sensibles en générant des URLs signées qui expirent après un certain laps de temps ou qui sont liées à des conditions spécifiques.

Voici un exemple de configuration Nginx utilisant la directive secure_link :

server {
    listen 80;
    server_name example.com;

    location /downloads {
        root /var/www/html;
        index index.html;
        secure_link $arg_md5,$arg_expires;
        secure_link_md5 "$secure_link_expires$uri$remote_addr secret";
        if ($secure_link = "") {
            return 403;
        }
    }
}

Dans cet exemple, la ligne secure_link $arg_md5,$arg_expires; définit les variables $arg_md5 et $arg_expires qui correspondent aux paramètres passés dans l'URL sécurisée. L'URL sécurisée doit contenir ces deux paramètres pour être considérée comme valide.

La ligne secure_link_md5 "$secure_link_expires$uri$remote_addr secret"; génère une signature MD5 basée sur les valeurs de $secure_link_expires (qui doit correspondre à la valeur du paramètre expires passé dans l'URL sécurisée), $uri (qui est l'URI de la ressource demandée) et $remote_addr (qui est l'adresse IP du client). secret est une clé secrète utilisée pour générer la signature.

Ensuite, nous utilisons une condition if ($secure_link = "") pour vérifier si l'URL sécurisée est valide. Si elle est vide, nous retournons une erreur 403, ce qui signifie que l'accès est interdit.

Cette configuration permet de générer des URLs sécurisées pour les ressources téléchargeables. Par exemple, une URL valide pourrait ressembler à http://example.com/downloads/file.zip?md5=abc123&expires=1656778400, où md5 est la signature MD5 générée et expires est le timestamp d'expiration de l'URL.

En espérant que ces 5 directives Nginx vous permettront de mieux sécuriser vos serveurs web et vos reverses proxys !