{"id":233,"date":"2026-06-18T16:41:41","date_gmt":"2026-06-18T16:41:41","guid":{"rendered":"https:\/\/shattered.io\/fr\/2026\/06\/18\/security-headers-nodejs\/"},"modified":"2026-06-18T16:48:42","modified_gmt":"2026-06-18T16:48:42","slug":"security-headers-nodejs","status":"publish","type":"post","link":"https:\/\/shattered.io\/fr\/2026\/06\/18\/security-headers-nodejs\/","title":{"rendered":"En-t\u00eates de S\u00e9curit\u00e9 HTTP en Node.js : 12 \u00c9tapes, 30 Min [2026]"},"content":{"rendered":"\n

Les en-t\u00eates de s\u00e9curit\u00e9 HTTP constituent la premi\u00e8re ligne de d\u00e9fense d’une application web. Pourtant, selon l’OWASP Top 10<\/a>, la mauvaise configuration de s\u00e9curit\u00e9 (A05) touche la majorit\u00e9 des applications test\u00e9es, et l’absence d’en-t\u00eates HTTP adapt\u00e9s reste l’une des failles les plus fr\u00e9quentes et les plus faciles \u00e0 corriger. En Node.js, la biblioth\u00e8que Helmet.js 8.1.0<\/strong> (plus de 2 millions de t\u00e9l\u00e9chargements hebdomadaires sur npm) permet d’ajouter 12 en-t\u00eates de s\u00e9curit\u00e9 en une seule ligne de code.<\/p>\n\n\n\n

Ce tutoriel couvre chaque en-t\u00eate en d\u00e9tail, sa configuration avec Helmet, les pi\u00e8ges courants et la v\u00e9rification de votre score de s\u00e9curit\u00e9. \u00c0 la fin, vous disposerez d’un projet Express complet, configur\u00e9 selon les standards 2026, pr\u00eat pour la production.<\/p>\n\n\n\n

Pourquoi les en-t\u00eates de s\u00e9curit\u00e9 sont essentiels en 2026<\/h2>\n\n\n\n

Un en-t\u00eate HTTP de s\u00e9curit\u00e9 est une directive envoy\u00e9e par le serveur au navigateur du client. Il indique au navigateur comment traiter le contenu de la page : quelles sources de scripts autoriser, si la connexion doit \u00eatre chiffr\u00e9e, si la page peut \u00eatre embarqu\u00e9e dans une iframe, etc. Sans ces en-t\u00eates, le navigateur applique des comportements par d\u00e9faut souvent permissifs qui ouvrent la porte aux attaques les plus r\u00e9pandues.<\/p>\n\n\n\n

Les attaques directement li\u00e9es \u00e0 des en-t\u00eates manquants ou mal configur\u00e9s incluent : le cross-site scripting (XSS), le clickjacking, le MIME sniffing, les attaques de type downgrade HTTPS, et la fuite d’informations via le Referer. La directive A05 de l’OWASP Top 10 2021<\/strong> classe explicitement la mauvaise configuration de s\u00e9curit\u00e9 parmi les 5 risques les plus critiques pour les applications web. La r\u00e9f\u00e9rence compl\u00e8te se trouve dans la HTTP Headers Cheat Sheet de l’OWASP<\/a>.<\/p>\n\n\n\n

En Node.js avec Express, les en-t\u00eates de s\u00e9curit\u00e9 ne sont pas activ\u00e9s par d\u00e9faut. Un serveur Express vierge renvoie des en-t\u00eates minimaux, dont le r\u00e9v\u00e9lateur X-Powered-By: Express<\/code> qui annonce la technologie utilis\u00e9e aux attaquants. La solution standardis\u00e9e dans l’\u00e9cosyst\u00e8me Node.js est Helmet.js<\/strong>, un middleware qui configure automatiquement 12 en-t\u00eates de s\u00e9curit\u00e9 et supprime X-Powered-By<\/code>. Avec plus de 2 millions de t\u00e9l\u00e9chargements hebdomadaires sur npm, Helmet est utilis\u00e9 dans la quasi-totalit\u00e9 des applications Express en production.<\/p>\n\n\n\n

La derni\u00e8re version stable, Helmet 8.1.0<\/strong> (sortie le 17 mars 2025), est celle que nous utilisons dans ce tutoriel. Elle apporte une configuration plus granulaire des en-t\u00eates Cross-Origin et un meilleur support des politiques de permissions modernes.<\/p>\n\n\n\n

Pr\u00e9requis et versions<\/h2>\n\n\n\n

Avant de commencer, v\u00e9rifiez que votre environnement correspond aux versions suivantes :<\/p>\n\n\n\n

Technologie<\/th>Version minimale<\/th>Version recommand\u00e9e 2026<\/th><\/tr><\/thead>
Node.js<\/td>18.x LTS<\/td>22.x LTS<\/td><\/tr>
npm<\/td>9.x<\/td>10.x<\/td><\/tr>
Express<\/td>4.18.x<\/td>5.x<\/td><\/tr>
Helmet.js<\/td>7.x<\/td>8.1.0<\/td><\/tr>
Syst\u00e8me d’exploitation<\/td>Linux \/ macOS \/ Windows<\/td>Ubuntu 24.04 LTS<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Connaissances requises : bases de JavaScript et de Node.js, utilisation basique de la ligne de commande, notions fondamentales de HTTP. Si vous d\u00e9butez avec l’authentification Node.js, consultez d’abord notre guide Authentification JWT en Node.js : 12 \u00e9tapes<\/a>.<\/p>\n\n\n\n

\u00c9tape 1 : Initialiser le projet Node.js<\/h2>\n\n\n\n

Cr\u00e9ez un dossier de travail et initialisez un nouveau projet Node.js avec npm :<\/p>\n\n\n\n

mkdir node-security-headers\ncd node-security-headers\nnpm init -y\nnpm install express helmet<\/code><\/pre>\n\n\n\n
Cette commande installe Express et Helmet dans leurs derni\u00e8res versions stables. V\u00e9rifiez les versions install\u00e9es :<\/p>\n\n\n\n
npm list express helmet<\/code><\/pre>\n\n\n\n
Sortie attendue :<\/p>\n\n\n\n
node-security-headers@1.0.0\n\u251c\u2500\u2500 express@5.0.1\n\u2514\u2500\u2500 helmet@8.1.0<\/code><\/pre>\n\n\n\n
Cr\u00e9ez ensuite le fichier principal app.js<\/code> avec une structure de base :<\/p>\n\n\n\n
const express = require('express');\nconst app = express();\n\napp.get('\/', (req, res) => {\n  res.json({ message: 'Serveur Node.js sans s\u00e9curit\u00e9' });\n});\n\napp.listen(3000, () => {\n  console.log('Serveur d\u00e9marr\u00e9 sur http:\/\/localhost:3000');\n});<\/code><\/pre>\n\n\n\n
Lancez le serveur et examinez les en-t\u00eates renvoy\u00e9s sans Helmet :<\/p>\n\n\n\n
node app.js &\ncurl -I http:\/\/localhost:3000\/<\/code><\/pre>\n\n\n\n
Sortie typique d’un serveur Express sans Helmet :<\/p>\n\n\n\n
HTTP\/1.1 200 OK\nX-Powered-By: Express\nContent-Type: application\/json; charset=utf-8\nContent-Length: 42\nDate: Wed, 18 Jun 2026 10:00:00 GMT\nConnection: keep-alive<\/code><\/pre>\n\n\n\n
On constate imm\u00e9diatement l’absence totale d’en-t\u00eates de s\u00e9curit\u00e9 et la pr\u00e9sence de X-Powered-By: Express<\/code> qui expose la technologie utilis\u00e9e. Un attaquant qui r\u00e9cup\u00e8re cet en-t\u00eate peut cibler directement les vuln\u00e9rabilit\u00e9s connues de la version d’Express utilis\u00e9e.<\/p>\n\n\n\n
\u00c9tape 2 : Int\u00e9grer Helmet avec la configuration par d\u00e9faut<\/h2>\n\n\n\n
L’int\u00e9gration de base de Helmet.js<\/a> requiert deux lignes de code. Modifiez app.js<\/code> :<\/p>\n\n\n\n
const express = require('express');\nconst helmet = require('helmet');\n\nconst app = express();\n\n\/\/ Helmet doit \u00eatre plac\u00e9 avant les routes\napp.use(helmet());\n\napp.get('\/', (req, res) => {\n  res.json({ message: 'Serveur Node.js s\u00e9curis\u00e9 avec Helmet' });\n});\n\napp.listen(3000, () => {\n  console.log('Serveur d\u00e9marr\u00e9 sur http:\/\/localhost:3000');\n});<\/code><\/pre>\n\n\n\n
Red\u00e9marrez et v\u00e9rifiez les en-t\u00eates avec Helmet actif :<\/p>\n\n\n\n
node app.js &\ncurl -I http:\/\/localhost:3000\/<\/code><\/pre>\n\n\n\n
Sortie avec Helmet en configuration par d\u00e9faut :<\/p>\n\n\n\n
HTTP\/1.1 200 OK\nContent-Security-Policy: default-src 'self';base-uri 'self';font-src 'self' https: data:;form-action 'self';frame-ancestors 'self';img-src 'self' data:;object-src 'none';script-src 'self';script-src-attr 'none';style-src 'self' https: 'unsafe-inline';upgrade-insecure-requests\nCross-Origin-Embedder-Policy: require-corp\nCross-Origin-Opener-Policy: same-origin\nCross-Origin-Resource-Policy: same-origin\nOrigin-Agent-Cluster: ?1\nReferrer-Policy: no-referrer\nStrict-Transport-Security: max-age=31536000; includeSubDomains\nX-Content-Type-Options: nosniff\nX-DNS-Prefetch-Control: off\nX-Download-Options: noopen\nX-Frame-Options: SAMEORIGIN\nX-Permitted-Cross-Domain-Policies: none\nX-XSS-Protection: 0\nContent-Type: application\/json; charset=utf-8<\/code><\/pre>\n\n\n\n
En une ligne, app.use(helmet())<\/code> a ajout\u00e9 12 en-t\u00eates de s\u00e9curit\u00e9 et supprim\u00e9 X-Powered-By<\/code>. Le tableau suivant r\u00e9sume le r\u00f4le de chaque en-t\u00eate :<\/p>\n\n\n\n
En-t\u00eate HTTP<\/th>Valeur par d\u00e9faut Helmet 8.x<\/th>Protection contre<\/th><\/tr><\/thead>
Content-Security-Policy<\/td>default-src ‘self’ + directives multiples<\/td>XSS, injection de code<\/td><\/tr>
Strict-Transport-Security<\/td>max-age=31536000; includeSubDomains<\/td>Downgrade HTTPS, SSL stripping<\/td><\/tr>
X-Frame-Options<\/td>SAMEORIGIN<\/td>Clickjacking<\/td><\/tr>
X-Content-Type-Options<\/td>nosniff<\/td>MIME sniffing<\/td><\/tr>
Referrer-Policy<\/td>no-referrer<\/td>Fuite d’URL sensibles<\/td><\/tr>
Cross-Origin-Embedder-Policy<\/td>require-corp<\/td>Cross-origin data leaks<\/td><\/tr>
Cross-Origin-Opener-Policy<\/td>same-origin<\/td>Cross-origin window attacks<\/td><\/tr>
Cross-Origin-Resource-Policy<\/td>same-origin<\/td>Spectre, cross-site reads<\/td><\/tr>
X-DNS-Prefetch-Control<\/td>off<\/td>Fuite DNS<\/td><\/tr>
X-Download-Options<\/td>noopen<\/td>Ex\u00e9cution automatique IE<\/td><\/tr>
X-Permitted-Cross-Domain-Policies<\/td>none<\/td>Flash, PDF cross-domain<\/td><\/tr>
X-XSS-Protection<\/td>0 (d\u00e9sactiv\u00e9 d\u00e9lib\u00e9r\u00e9ment)<\/td>N\/A (obsol\u00e8te, dangereux en mode actif)<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\u00c9tape 3 : Configurer Content-Security-Policy (CSP)<\/h2>\n\n\n\n
La Content-Security-Policy<\/strong> (CSP) est l’en-t\u00eate le plus puissant et le plus complexe \u00e0 configurer. Elle d\u00e9finit les sources autoris\u00e9es pour chaque type de ressource : scripts, styles, images, polices, iframes, etc. Un CSP mal configur\u00e9 peut soit bloquer les ressources l\u00e9gitimes de votre application, soit laisser des failles XSS ouvertes. La sp\u00e9cification MDN sur la Content-Security-Policy<\/a> liste l’ensemble des directives disponibles.<\/p>\n\n\n\n
En pratique, les directives les plus importantes sont :<\/p>\n\n\n\n
Directive CSP<\/th>R\u00f4le<\/th>Valeur s\u00e9curis\u00e9e recommand\u00e9e<\/th><\/tr><\/thead>
default-src<\/td>Source par d\u00e9faut pour tout type de ressource<\/td>‘self’<\/td><\/tr>
script-src<\/td>Sources des scripts JavaScript<\/td>‘self’ + nonce pour scripts inline<\/td><\/tr>
style-src<\/td>Sources des feuilles de style CSS<\/td>‘self’ https:<\/td><\/tr>
img-src<\/td>Sources des images<\/td>‘self’ data: https:<\/td><\/tr>
font-src<\/td>Sources des polices de caract\u00e8res<\/td>‘self’ https: data:<\/td><\/tr>
connect-src<\/td>Sources pour fetch(), XHR, WebSocket<\/td>‘self’<\/td><\/tr>
frame-ancestors<\/td>Qui peut embarquer la page dans une iframe<\/td>‘none’ ou ‘self’<\/td><\/tr>
object-src<\/td>Sources pour Flash, plugins<\/td>‘none’<\/td><\/tr>
base-uri<\/td>Restreint la balise <base><\/td>‘self’<\/td><\/tr>
upgrade-insecure-requests<\/td>Force le chargement HTTPS des ressources HTTP<\/td>Actif en production<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Voici une configuration CSP r\u00e9aliste pour une application Express avec API REST et ressources statiques :<\/p>\n\n\n\n
const express = require('express');\nconst helmet = require('helmet');\n\nconst app = express();\n\napp.use(\n  helmet({\n    contentSecurityPolicy: {\n      directives: {\n        defaultSrc: [\"'self'\"],\n        scriptSrc: [\"'self'\"],\n        styleSrc: [\"'self'\", 'https:', \"'unsafe-inline'\"],\n        imgSrc: [\"'self'\", 'data:', 'https:'],\n        fontSrc: [\"'self'\", 'https:', 'data:'],\n        connectSrc: [\"'self'\"],\n        frameAncestors: [\"'none'\"],\n        objectSrc: [\"'none'\"],\n        upgradeInsecureRequests: [],\n        reportUri: '\/csp-report',\n      },\n    },\n  })\n);\n\n\/\/ Endpoint pour recevoir les rapports de violations CSP\napp.post('\/csp-report', express.json({ type: 'application\/csp-report' }), (req, res) => {\n  console.log('Violation CSP d\u00e9tect\u00e9e:', JSON.stringify(req.body, null, 2));\n  res.status(204).end();\n});\n\napp.get('\/', (req, res) => {\n  res.json({ message: 'API s\u00e9curis\u00e9e avec CSP' });\n});\n\napp.listen(3000);<\/code><\/pre>\n\n\n\n
Pour les applications qui utilisent des CDN (Google Fonts, Bootstrap, etc.), ajoutez explicitement ces domaines dans les directives concern\u00e9es. Si votre front-end utilise des scripts inline ou des gestionnaires d’\u00e9v\u00e9nements inline, l’approche recommand\u00e9e en 2026 est d’utiliser des nonces CSP<\/strong> plut\u00f4t que 'unsafe-inline'<\/code>.<\/p>\n\n\n\n
CSP en mode rapport uniquement (recommand\u00e9 pour le d\u00e9ploiement initial)<\/h3>\n\n\n\n
Pendant le d\u00e9ploiement initial, activez d’abord le mode rapport (Content-Security-Policy-Report-Only<\/code>) pour d\u00e9tecter les violations sans bloquer les ressources l\u00e9gitimes :<\/p>\n\n\n\n
app.use(\n  helmet({\n    contentSecurityPolicy: {\n      reportOnly: true, \/\/ Observe les violations sans bloquer\n      directives: {\n        defaultSrc: [\"'self'\"],\n        scriptSrc: [\"'self'\"],\n        reportUri: '\/csp-report',\n      },\n    },\n  })\n);<\/code><\/pre>\n\n\n\n
Consultez les logs des violations pendant 24 \u00e0 48 heures, ajustez les directives pour les sources l\u00e9gitimes, puis basculez en mode enforcement en supprimant reportOnly: true<\/code>. Cette approche \u00e9vite de bloquer des ressources l\u00e9gitimes en production.<\/p>\n\n\n\n
\u00c9tape 4 : HTTP Strict Transport Security (HSTS)<\/h2>\n\n\n\n
L’en-t\u00eate Strict-Transport-Security<\/strong> (HSTS) force le navigateur \u00e0 utiliser exclusivement HTTPS pour toutes les communications avec votre domaine pendant une dur\u00e9e d\u00e9finie. Une fois que le navigateur a re\u00e7u cet en-t\u00eate, il refuse toute connexion HTTP et convertit automatiquement toutes les requ\u00eates en HTTPS, m\u00eame si l’utilisateur tape http:\/\/<\/code> dans la barre d’adresse.<\/p>\n\n\n\n
HSTS prot\u00e8ge contre les attaques de type SSL stripping<\/em>, o\u00f9 un attaquant plac\u00e9 en position de man-in-the-middle intercepte la connexion initiale HTTP avant la redirection vers HTTPS. La configuration par d\u00e9faut de Helmet d\u00e9finit un HSTS de 365 jours (31 536 000 secondes) avec includeSubDomains<\/code>. Pour la production, ajoutez preload<\/code> pour soumettre votre domaine \u00e0 la liste de pr\u00e9chargement HSTS int\u00e9gr\u00e9e aux navigateurs :<\/p>\n\n\n\n
app.use(\n  helmet({\n    hsts: {\n      maxAge: 31536000,         \/\/ 365 jours en secondes\n      includeSubDomains: true,  \/\/ Applique HSTS \u00e0 tous les sous-domaines\n      preload: true,            \/\/ Soumet le domaine \u00e0 la liste HSTS preload\n    },\n  })\n);<\/code><\/pre>\n\n\n\n
Points critiques sur la configuration HSTS :<\/p>\n\n\n\n