Cette traduction fournie par StrongLoop / IBM.

Il se peut que ce document soit obsolète par rapport à la documentation en anglais. Pour connaître les mises à jour les plus récentes, reportez-vous à la documentation en anglais.

✖

Meilleures pratiques en production : Sécurité

Présentation

Le terme “production” fait référence à la phase du cycle de vie du logiciel au cours de laquelle une application ou une API est généralement disponible pour ses consommateurs ou utilisateurs finaux. En revanche, en phase de “développement”, l’écriture et le test de code se poursuivent activement et l’application n’est pas ouverte pour un accès externe. Les environnements système correspondants sont respectivement appelés environnement de production et environnement de développement.

Les environnements de développement et de production sont généralement configurés différemment et leurs exigences divergent grandement. Ce qui convient parfaitement en développement peut être inacceptable en production. Par exemple, dans un environnement de développement, vous pouvez souhaiter une consignation prolixe des erreurs en vue du débogage, alors que ce type de comportement présente des risques au niveau de sécurité en environnement de production. De plus, en environnement de développement, vous n’avez pas à vous soucier de l’extensibilité, de la fiabilité et des performances, tandis que ces éléments sont essentiels en environnement de production.

Cet article traite des meilleures pratiques en terme de sécurité pour les applications Express déployées en production.

N’utilisez pas de versions obsolètes ou vulnérables d’Express

Les versions 2.x et 3.x d’Express ne sont plus prises en charge. Les problèmes liés à la sécurité et aux performances dans ces versions ne seront pas corrigés. Ne les utilisez pas ! Si vous êtes passé à la version 4, suivez le guide de migration.

Vérifiez également que vous n’utilisez aucune des versions vulnérables d’Express répertoriées sur la page Mises à jour de sécurité. Si tel est le cas, procédez à une mise à jour vers une version stable, de préférence la plus récente.

Utilisez TLS

Si votre application traite ou transmet des données sensibles, utilisez TLS (Transport Layer Security) afin de sécuriser la connexion et les données. Cette technologie de l’information chiffre les données avant de les envoyer du client au serveur, ce qui vous préserve des risques d’hameçonnage les plus communs (et faciles). Même si les requêtes Ajax et POST ne sont pas clairement visibles et semblent “masquées” dans les navigateurs, leur trafic réseau n’est pas à l’abri d’une détection de paquet ni des attaques d’intercepteur.

Vous connaissez sans doute le chiffrement SSL (Secure Socket Layer). TLS est simplement une évolution de SSL. En d’autres termes, si vous utilisiez SSL auparavant, envisagez de passer à TLS. Nous recommandons généralement Nginx pour gérer TLS. Pour des informations de référence fiables concernant la configuration de TLS sur Nginx (et d’autres serveurs), voir Configurations de serveur recommandées (wiki Mozilla).

Par ailleurs, un outil très pratique, Let’s Encrypt, autorité de certification gratuite, automatisée et ouverte fournie par le groupe de recherche sur la sécurité sur Internet, ISRG (Internet Security Research Group), vous permet de vous procurer gratuitement un certificat TLS.

Utilisez Helmet

Helmet vous aide à protéger votre application de certaines des vulnérabilités bien connues du Web en configurant de manière appropriée des en-têtes HTTP.

Helmet n’est actuellement qu’une collection de neuf fonctions middleware plus petites qui définissent des en-têtes HTTP liés à la sécurité :

Installez Helmet comme n’importe quel autre module :

$ npm install --save helmet

Puis, pour l’utiliser dans votre code :

/// ...

const helmet = require('helmet')
app.use(helmet())

/// ...

Désactivez au minimum l’en-tête X-Powered-By

Si vous ne voulez pas utiliser Helmet, désactivez au minimum l’en-tête X-Powered-By. Les intrus peuvent utiliser cet en-tête (activé par défaut) afin de détecter les applications qui exécutent Express et lancer ensuite des attaques spécifiquement ciblées.

Il est donc conseillé de neutraliser l’en-tête à l’aide de la méthode app.disable() comme suit :

app.disable('x-powered-by')

Si vous utilisez helmet.js, cette opération s’effectue automatiquement.

Utilisez les cookies de manière sécurisée

Pour garantir que les cookies n’ouvrent pas votre application aux attaques, n’utilisez pas le nom du cookie de session par défaut et définissez de manière appropriée des options de sécurité des cookies.

Il existe deux modules principaux de session de cookie de middleware :

La principale différence entre ces deux modules tient à la manière dont ils sauvegardent les données de session des cookies. Le middleware express-session stocke les données de session sur le serveur ; il ne sauvegarde que l’ID session dans le cookie lui-même, mais pas les données de session. Par défaut, il utilise le stockage en mémoire et n’est pas conçu pour un environnement de production. En production, vous devrez configurer un magasin de sessions évolutif (voir la liste des magasins de sessions compatibles).

En revanche, le middleware cookie-session implémente un stockage sur cookie, c’est-à-dire qu’il sérialise l’intégralité de la session sur le cookie, et non simplement une clé de session. Utilisez-le uniquement lorsque les données de session sont relativement peu nombreuses et faciles à coder sous forme de valeurs primitives (au lieu d’objets). Même si les navigateurs sont censés prendre en charge au moins 4096 octets par cookie, pour ne pas risquer de dépasser cette limite, limitez-vous à 4093 octets par domaine. De plus, n’oubliez pas que les données de cookie seront visibles du client et que s’il n’est pas nécessaire qu’elles soient sécurisées ou illisibles, express-session est probablement la meilleure solution.

L’utilisation d’un nom de cookie de session par défaut risque d’ouvrir votre application aux attaques. Le problème de sécurité qui en découle est similaire à X-Powered-By : une personne potentiellement malveillante peut l’utiliser pour s’identifier auprès du serveur et cibler ses attaques en conséquence.

Pour éviter ce problème, utilisez des noms de cookie génériques, par exemple à l’aide du middleware express-session :

const session = require('express-session')
app.set('trust proxy', 1) // trust first proxy
app.use(session({
  secret: 's3Cur3',
  name: 'sessionId'
})
)

Définissez les options de cookie suivantes pour accroître la sécurité :

Exemple d’utilisation du middleware cookie-session :

const session = require('cookie-session')
const express = require('express')
const app = express()

const expiryDate = new Date(Date.now() + 60 * 60 * 1000) // 1 hour
app.use(session({
  name: 'session',
  keys: ['key1', 'key2'],
  cookie: {
    secure: true,
    httpOnly: true,
    domain: 'example.com',
    path: 'foo/bar',
    expires: expiryDate
  }
})
)

Autres considérations

Voici d’autres recommandations issues de l’excellente liste de contrôle de sécurité Node.js. Pour tous les détails sur ces recommandations, reportez-vous à cet article de blogue :

Eviter les autres vulnérabilités connues

Gardez un oeil sur les recommandations Node Security Project qui peuvent concerner Express ou d’autres modules utilisés par votre application. En règle générale, Node Security Project est une excellente ressource de connaissances et d’outils sur la sécurité de Node.

Pour finir, les applications Express - comme toutes les autres applications Web - peuvent être vulnérables à une variété d’attaques Web. Familiarisez vous avec les vulnérabilités Web connues et prenez des précautions pour les éviter.