🛡️ Node.js en frontal : rapide, pratique… suicidaire ?

Pourquoi sécuriser votre stack Node.js avec un reverse proxy est un réflexe vital (et pas juste une option pour les paranos).

Node.js, entre agilité et naïveté

« Il est si facile de démarrer avec Node.js qu’on oublie parfois qu’on est en train de construire une application… exposée au monde entier. »

Node.js, c’est un peu le couteau suisse du développeur moderne : rapide, léger, capable de tout faire — des API REST aux applications temps réel en passant par le rendu côté serveur. En quelques lignes de code, vous avez un serveur HTTP opérationnel, une route d’authentification, et pourquoi pas une app React servie en statique. Génial.

Et c’est bien là le problème.

À force de tout centraliser dans une seule instance Node, de nombreux projets finissent par tourner en production exactement comme en développement : sans reverse proxy, sans gestion SSL dédiée, sans filtres, sans limites. Bref, sans protection. L’illusion de la simplicité masque une réalité bien plus inquiétante : exposer Node.js directement à Internet, c’est tendre la joue aux scanners, bots, et script kiddies qui peuplent le web.

Certes, “ça marche”. Jusqu’au jour où un script de brute-force fait tomber le serveur, où une stack trace révèle des infos critiques, ou où un simple oubli de header transforme ton appli en moulin à XSS.

Dans cet article, on va décortiquer :

• pourquoi servir une app Node.js sans reverse proxy est une erreur stratégique (et un suicide opérationnel),
• comment protéger à la fois le front et le back de votre stack Node,
• et pourquoi un NGINX bien configuré vaut tous les helmet() du monde.

Spoiler : non, Node.js n’est pas fait pour être laissé sans surveillance en première ligne. Et oui, on va te le prouver.

🧱 Architecture “tout Node” : la fausse bonne idée

« Pourquoi s’embêter avec un reverse proxy quand on peut tout balancer sur un app.listen(3000) et appeler ça de l’ingénierie ? »

La tentation est grande. Node.js permet de monter un serveur web en 10 lignes chrono. Un express.static() pour les assets, quelques routes, et bim, on a une appli “fullstack” qui tourne. Pourquoi rajouter de la complexité ? Après tout, c’est agile, non ?

En réalité, ce type d’architecture dite “tout Node” repose sur une illusion de simplicité. Certes, pour une démo interne ou un projet étudiant, ça fait le job. Mais en production ? C’est un peu comme rouler sur l’autoroute avec une trottinette sans freins : tant que tout va bien, tout va bien.

🚀 Exemple d’architecture “tout Node”

js
const express = require('express');
const app = express();

app.use(express.static('public'));
app.use('/api', require('./routes/api'));

app.listen(3000, () => {
  console.log('Server running on http://localhost:3000');
});

✨ Magique. Tu sers les fichiers statiques, les routes, tu gères tout avec Express. Pas besoin de NGINX, pas besoin d’Apache. Pas besoin de cerveau non plus, si on pousse l’analyse.

🧨 Ce que cette architecture implique (sans que tu le réalises forcément) :

• Node devient ton serveur HTTP complet : or, ce n’est pas son métier.
• Tu charges le runtime JavaScript pour servir un .jpg. L’équivalent de cuire un œuf avec un chalumeau.
• Tu perds tous les avantages d’un vrai front-end statique (cache, compression, header fine-tuning).
• Tu exposes directement ton port Node à Internet, donc à tout ce qui traîne dessus (bots, vulnérabilités, erreurs de dev).
• Tu rends ton app monolithique et fragile : une erreur uncaught dans une route, et ton app entière tombe (sauf si tu colles un pm2 en mode pansement).

🤹 Cas d’usage typique :

• Petits projets ou MVPs en VPS chez OVH, DigitalOcean & co.
• Déploiement Heroku / Render sans proxy personnalisé.
• Docker “quick & dirty” avec juste un EXPOSE 3000.

Et tu sais quoi ? Ça marche. Vraiment. Jusqu’au jour où tu as du trafic réel, des attaques, ou simplement… des utilisateurs.

Morale temporaire : ce n’est pas parce qu’on peut tout faire avec Node.js qu’on doit tout faire avec lui.
Tu peux aussi faire un café avec une poêle à frire — mais il y a de meilleures options.

🚨 Les risques concrets d’exposer Node directement sur Internet

« Ouvrir Node sur le port 80, c’est comme laisser la porte de ta maison grande ouverte avec un panneau “je reviens dans 5 minutes”. »

Tu as décidé d’exposer ton application Node.js directement à Internet. Après tout, t’as lancé le listen(3000), ça fonctionne, pas besoin de reverse proxy, non ? Erreur fatale.
Voici ce que tu t’apprêtes à affronter, façon grand écart facial sans échauffement.

🧨 1. Pas de protection contre les attaques courantes

Node.js, tout seul, n’a aucun mécanisme natif de défense contre les classiques du genre :

• Flood HTTP / DDoS léger → ton event loop prend feu, ton app tombe.
• Brute-force login → pas de rate limiting, pas de fail2ban.
• Scans de vulnérabilités automatiques → pas d’IP banning, ni de honeypot, tu sers le buffet.

“Oui mais j’ai mis express-rate-limit…”
Ok, et si l’attaquant t’envoie 10 000 connexions simultanées par IP différente ? Bonne chance.

🧾 2. Pas d’en-têtes de sécurité HTTP

Pas de NGINX, pas de helmet, pas de add_header, donc :

• Pas de HSTS → tes utilisateurs peuvent se faire downgrader en HTTP.
• Pas de CSP → XSS bonjour.
• Pas de X-Frame-Options → ton app peut être embarquée dans un site tiers (clickjacking).
• Pas de X-Content-Type-Options → injection MIME ? Why not.

Et si tu penses que les headers, c’est cosmétique… demande aux gens de chez Equifax.

🐛 3. Fuites d’erreurs et de stack trace

Par défaut, Express ou Koa affichent les erreurs avec un niveau de détail… intimiste :

• Stack trace complète (avec chemin du fichier, noms des variables)
• Libs NPM utilisées
• Infos système, parfois même… le chemin absolu du serveur.

💀 Bravo, tu viens de faire gagner 30 minutes à l’attaquant.

🪵 4. Pas de logs d’accès ni de gestion fine des erreurs

• Pas de format commun pour tes logs (combined, common, etc.)
• Pas de rotation, pas de compression
• Aucune séparation front/back, aucun anonymat IP

Tu veux tracer un incident ? Bon courage avec ton console.log("req.body") dans un coin.

🐌 5. Surcharge de Node avec les fichiers statiques

Chaque image, chaque CSS, chaque favicon… tout passe par ton serveur Node monothread JS.

• Résultat : tu perds de la perf là où NGINX brille.
• Tu te bats contre les navigateurs pour gérer les caches correctement.
• Tu redécouvres la douleur du ETag, du Cache-Control, et des 304 Not Modified manuels.

Et pendant ce temps, ton process Node rame parce qu’un PNG de 8 Mo est en cours de téléchargement.

🔓 6. Surface d’attaque élargie

Tu exposes le cœur de ton appli à Internet, au lieu de cloisonner :

• Chaque dépendance NPM est une porte d’entrée potentielle.
• Une simple faille dans un middleware peut devenir un RCE (Remote Code Execution).
• Le moindre require('fs') peut virer au drame si un chemin utilisateur mal vérifié arrive là.

📊 Comparatif Express vs NGINX sur les risques

Moralité : ce n’est pas que Node est vulnérable.
C’est juste qu’il n’a pas été conçu pour se battre seul en première ligne.
C’est un excellent back-end, pas un bouclier.

🎭 Sécurité côté FRONT : les oublis classiques

« Le front, c’est ce qui brille. Et ce qui attire les attaques comme les moustiques sur un lampadaire. »

Quand on parle de sécurité front-end dans un projet Node.js, beaucoup de développeurs lèvent les yeux au ciel en pensant : « Bof, j’ai mis du HTTPS, on est bons, non ? »
Pas vraiment.

Dans une architecture où Node.js sert aussi le front (SSR, templates, assets statiques ou même React en mode res.sendFile()), chaque oubli, chaque négligence peut transformer ton app en faille géante sur pattes. Voici le florilège des “classiques”.

❌ 1. Pas de helmet() → pas de casques

Express n’impose rien. Tu veux des en-têtes de sécurité ? Tu dois les rajouter toi-même. Et si tu oublies helmet, tu exposes ta surface d’attaque à :

• XSS persistants (pas de CSP)
• Clickjacking (pas de X-Frame-Options)
• Sniffing de contenu (pas de X-Content-Type-Options)
• Downgrade HTTP (pas de Strict-Transport-Security)

Tu n’as pas mis helmet() ? Félicitations, tu offres une visite guidée de ton app aux attaquants.

🌀 2. CORS : plus tu ouvres, plus tu pleures

Dans la précipitation, beaucoup de devs activent CORS en mode :

js
app.use(cors({ origin: '*' }));

Autrement dit : “Venez comme vous êtes, avec vos scripts douteux et vos cookies volés.”

Un CORS mal configuré, c’est la porte ouverte au vol de données par des domaines tiers, à des attaques XSS cross-domain, ou à des appels API non désirés. Bref, un vrai tapis rouge.

🍪 3. Cookies non sécurisés

Node ne chiffre rien par défaut. Si tu ne spécifies pas :

• httpOnly: true
• secure: true
• sameSite: 'Strict'

… alors tes cookies de session peuvent être :

• lus par du JS malicieux (bye bye httpOnly)
• envoyés en clair sur HTTP (bye bye secure)
• transmis à tout va d’un site à un autre (bye bye sameSite)

Et là, un attaquant récupère une session valide, et… il est toi.

🧠 4. Rendu serveur : les injections sournoises

Utiliser un moteur de template (ejs, pug, handlebars…) ou du SSR (React, Vue, etc.) ? Alors bienvenue dans la jungle du XSS dans le rendu serveur.

• Une variable mal échappée = exécution de JS.
• Un lien dynamique non contrôlé = phishing interne.
• Un composant React SSR sans dangerouslySetInnerHTML maîtrisé = fail immédiat.

Oui, même {{ userInput }} peut devenir dangereux si tu crois que tout ce que le user t’envoie est gentil.

🧱 5. Mauvaise gestion du cache HTTP

• Cache-Control: public, max-age=3600 sur des routes dynamiques = fuite potentielle de données.
• Pas d’ETag ou Last-Modified = rechargement à chaque fois.
• Cache partagé entre users non authentifiés et authentifiés = gros fail de confidentialité.

📦 Exemple concret : faille XSS dans un moteur de template Express

<!-- Vulnérable -->
<h1>Bienvenue <%= user.name %></h1>

Avec une entrée :

js
user.name = "<script>alert('XSS!')</script>"

Boom 💥. Tu viens d’armer une faille XSS en prod. Félicitations.

🔐 Rappels de bonnes pratiques côté front :

• Active helmet() avec une configuration adaptée.
• Configure finement cors(), pas de '*' sauf pour les assets publics.
• Définis toujours secure, httpOnly, sameSite sur les cookies.
• Échappe toujours les données dans les templates.
• Gère les headers de cache avec soin : différencie statique/dynamique.

Moralité : Le front, c’est la vitrine. Tu peux avoir un back en béton, si ton front est une passoire, tout tombe.
Et non, console.log("XSS ?") dans le navigateur, ça ne compte pas comme protection.

🔧 Sécurité côté BACK : ce que les devs sous-estiment

« Tu n’as pas mis de validation d’input ? Pas de souci, quelqu’un d’autre va s’en charger à ta place. Probablement un bot russe. »

Node.js côté serveur est souvent perçu comme un environnement moderne, propre, modulaire. C’est vrai.
Mais ça ne le rend ni sûr, ni à l’abri des erreurs de développeurs pressés.

Petit tour des oublis classiques qui transforment ton back en cheval de Troie déguisé en API RESTful.

💣 1. Paquets NPM vérolés, obsolètes ou jamais mis à jour

• L’écosystème Node, c’est le Far West : tout est open, tout est forké, et tout le monde publie.
• Chaque dépendance que tu installes, c’est une confiance implicite.
• Certaines lib ont été piratées ou remplacées par des malwares (ex: event-stream, coa, etc.).

Et toi, tu continues à faire :

bash
npm install leftpad-magic

Sans audit. Sans sourciller.

📌 À faire : npm audit systématiquement, ou mieux, utiliser snyk en CI/CD.

🐛 2. Absence de validation des entrées utilisateurs

Node ne valide rien. Tu dois tout faire manuellement. Tu reçois un req.body.email ?
Tu espères qu’il contient bien un email ? Bon courage.

Et si tu fais ça :

js
if (req.query.admin === 'true') {
  grantAccess();
}

… alors prépare-toi à voir ce paramètre apparaître dans des dizaines de requêtes malveillantes dans tes logs (si tu loggais, mais tu ne logges pas, on sait).

📌 Solution : utiliser zod, joi, express-validator, ou te faire auditer par un vrai humain.

💀 3. Mauvaise gestion des erreurs → fuite d’infos

Exemple classique :

js
app.get('/admin', (req, res) => {
  throw new Error('Accès refusé');
});

Résultat :

javascript
Error: Accès refusé
    at ...
    at server.js:12:15
    at ...

Boom : stack trace en clair, infos système, path absolus, ligne de code. Le rêve pour un attaquant.

📌 En prod, toujours capturer les erreurs globales (process.on('uncaughtException'), middleware d’erreur Express) et afficher un message générique au client.

🔓 4. Accès aux fichiers ou aux commandes système

Node permet des trucs puissants. Genre exécuter des commandes shell :

js
exec(`rm -rf ${req.query.path}`);

😱 Ce que tu viens d’écrire, c’est littéralement un RCE en mode tourniquet.
Et non, un path.includes('..') ne suffit pas à te protéger.

🔑 5. Authentification maison ou token mal validé

• Tu veux “coder ton propre JWT middleware” ? Mauvaise idée.
• Tu signes ton token sans date d’expiration ?
• Tu oublies de vérifier l’audience, le issuer, ou tu fais :

js
jwt.verify(token, 'mySecret');

…alors que ton secret est dans ton fichier .env… exposé dans GitHub ?

🔐 Résultat : replays, escalade de privilèges, comptes usurpés.

💡 6. Middlewares douteux ou empilés n’importe comment

Tu mets tous tes app.use() en haut sans y penser :

• CORS ouvert à tous
• BodyParser même sur /admin
• Logger qui log les mots de passe
• Middleware d’auth à la fin du fichier, après les routes

Résultat : routes accessibles sans auth, logs de credentials, CORS bypass complet.

📎 Bonnes pratiques à ne jamais oublier côté back :

Moralité : coder une API, c’est bien. Coder une API fiable, sécurisée et maintenable, c’est un métier. Et ce métier commence par admettre que Node ne fait rien de sécurisé par défaut. Rien. Nada. Zero. Tu dois tout penser. Ou alors, prier.

🛡️ Le reverse proxy : armure, pare-chocs et pare-balles

« Un reverse proxy, c’est comme un videur de boîte de nuit : il filtre, il encaisse, il redirige. Et surtout, il évite que ton back-end se prenne une bouteille dans la tête à 2h du mat’. »

Quand on parle de sécurité et de performance en production, une règle est simple :

Ne laisse jamais ton serveur Node.js gérer seul les requêtes en frontal. Jamais.

Pourquoi ? Parce que ce n’est pas son rôle, et parce qu’un reverse proxy (comme NGINX, Apache, ou Caddy) le fait bien mieux, plus vite, et avec plus de style.

🧰 Que fait un reverse proxy que Node ne fera jamais bien (ou pas du tout) ?

🔒 1. Gère les connexions HTTPS comme un chef

• Terminaison SSL, redirection HTTP → HTTPS automatique.
• Renouvellement auto avec Let’s Encrypt.
• Prise en charge de TLS 1.3, ALPN, HTTP/2.
• Filtrage des protocoles ou ciphers vulnérables.

Avec Node, tu dois tout gérer manuellement (ou coller https dans ton code, avec fs.readFileSync() sur des certifs… mal sécurisés).

🧱 2. Protège contre le flood, le brute-force, le flood lent (DoS)

• Limitations de connexions par IP (limit_req, limit_conn)
• Timeout configurable par URI, méthode, User-Agent…
• Bufferisation, file d’attente de requêtes
• Rejet des clients trop lents ou trop bavards (Slowloris mitigation)

Node.js, lui, accepte les connexions comme un serveur TGV qui aurait désactivé les freins.

🎯 3. Optimise la distribution des assets statiques

• Gzip automatique
• Cache Cache-Control, ETag, Last-Modified
• Délivrance d’assets depuis /var/www/html sans passer par Node
• Gestion du fallback HTML (ex: Angular/React routes)

Tu ne charges plus le runtime JS pour servir une image. Et ton CPU dit merci.

🧱 4. Ajoute les headers de sécurité côté serveur

Avec NGINX :

nginx
add_header Strict-Transport-Security "max-age=31536000" always;
add_header X-Frame-Options "DENY";
add_header X-Content-Type-Options "nosniff";
add_header Referrer-Policy "no-referrer";

Et voilà. Sans écrire une seule ligne JS. Avec Node, tu dois prier pour que helmet() couvre tout… et que tu n’oublies rien.

🔁 5. Fait du load balancing, du failover, du caching

• Tu as plusieurs instances Node ? NGINX peut distribuer les requêtes.
• Une instance tombe ? Il redirige.
• Besoin de cache côté client/serveur ? C’est natif.

Node, lui, panique si tu ouvres plus de 500 connexions simultanées.

💬 Extrait de conf NGINX pour proxy Node.js :

nginx
server {
  listen 80;
  server_name monapp.exemple.com;

  location / {
    proxy_pass http://localhost:3000;
    proxy_http_version 1.1;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
  }

  add_header X-Frame-Options "DENY";
  add_header X-Content-Type-Options "nosniff";
}

En 15 lignes, tu protèges ton serveur, ajoutes des headers de sécurité, cloisonnes le Node backend, et poses une première ligne de défense. Tu veux vraiment t’en passer ?

📊 Comparatif Node seul vs Node derrière NGINX :

Moralité : Mettre un reverse proxy devant Node, c’est comme mettre un casque avant une descente en VTT.
Sans lui, tu vas peut-être survivre. Mais tu risques de finir avec les dents dans le guidon.

🧠 Bonnes pratiques pour sécuriser une app Node.js

« Node.js, c’est un peu comme un enfant surdoué : très prometteur, mais à surveiller en permanence si tu veux pas qu’il foute le feu à la cuisine. »

Tu as compris que Node tout seul, c’est pas un pare-feu.
Tu as ajouté un NGINX en frontal : bravo, tu ne fais plus partie des 80% de devs qui mettent leur API en production à poil.
Maintenant, reste à blinder ton code Node, parce qu’un reverse proxy ne corrige pas une mauvaise logique métier ou un middleware foireux.

Voici les bonnes pratiques à mettre en place côté Node, classées par niveau de conscience professionnelle 👇

🛡️ 1. Sécuriser le serveur Express

• helmet() → pour activer tous les headers HTTP importants :

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

• express-rate-limit → pour limiter les tentatives (login, brute-force…) :

js
const rateLimit = require('express-rate-limit');
app.use(rateLimit({ windowMs: 1 * 60 * 1000, max: 100 }));

• cors() → configuration fine par origine, méthode, credentials :

js
app.use(cors({
  origin: 'https://votresite.com',
  methods: ['GET', 'POST'],
  credentials: true
}));

• express.json({ limit: '1kb' }) → limite la taille des payloads JSON.

📌 Ne laissez jamais les valeurs par défaut. Par défaut, Express est… permissif.

🧼 2. Valider toutes les entrées utilisateur

Tu ne fais confiance à aucune entrée : que ce soit query, body, params, ou headers.
Utilise :

• zod (TS-friendly, moderne)
• joi (robuste et historique)
• express-validator (intégré dans le routeur Express)

Si tu n’as pas validé, tu as potentiellement laissé passer une injection, un overflow, ou une attaque logique.

🔐 3. Protéger l’authentification et les tokens

• Ne code jamais ton propre JWT parser.
• Toujours vérifier :
  • exp (expiration)
  • aud, iss (audience et émetteur)
  • signature avec un secret stocké en dehors du code
• Renouvelle régulièrement les tokens, supporte le refresh.
• Blackliste les tokens compromis (ou utilise des short-lived + rotation).

🔍 4. Journalisation propre et utile

Utilise winston, pino ou bunyan :

• Pas de console.log() en prod.
• Logge les erreurs, les comportements anormaux, les accès admin.
• Mais jamais les req.body.password, token, session, etc.
• Active la rotation des logs, surtout sur VPS / Docker.

🧯 5. Gérer proprement les erreurs

• Middleware global Express :

js
app.use((err, req, res, next) => {
  console.error(err);
  res.status(500).json({ message: "Erreur interne. Contactez le support." });
});

• Catch global :

js
process.on('uncaughtException', (err) => {
  // Log + graceful shutdown
});

Un serveur qui tombe sur un simple .toLowerCase() d’une valeur undefined, ça arrive plus souvent que tu ne crois.

🧩 6. Auditer et sécuriser les dépendances

• npm audit fix
• snyk test
• Vérifie les permissions de ton package.json (scripts postinstall douteux)
• Désinstalle les libs inutilisées (réduit la surface d’attaque)

🪵 7. Séparer config, secrets et environnement

• Utilise des fichiers .env, mais jamais dans Git
• Dans Docker ou VPS : variables d’environnement uniquement
• Pas de mot de passe en clair dans le code (jamais)
• Pas de debug actif (NODE_ENV=production, sinon Express balance trop d’infos)

⚙️ 8. Superviser et redémarrer automatiquement

• Utilise pm2 pour :
  • Superviser les crashs
  • Redémarrer automatiquement
  • Logger proprement
• Combine avec uptime-kuma, Grafana, ou ELK pour de la supervision

✅ Checklist finale “Node.js sécurisé en prod”

Moralité : sécuriser ton app Node, ce n’est pas juste “mettre un reverse proxy” ou “passer un pentest à la fin”.
C’est penser la sécurité comme une fonctionnalité dès le premier npm init.

🎬 Conclusion : “Tu veux jouer à l’administrateur web ? Alors fais-le bien.”

« Un app.listen(3000) en production, c’est pas une preuve de minimalisme. C’est une déclaration de guerre… à ton propre service IT. »

Node.js est un outil puissant. Trop puissant, parfois, pour ceux qui l’utilisent comme un lance-pierre alors que c’est un lance-flammes.
La tentation de tout servir depuis une seule instance Express, sans reverse proxy, sans validation, sans audit, peut sembler pragmatique. C’est rapide, non ?

Oui. Comme une descente de piste noire sans casque.

Dans ce dossier, on a vu que :

• Node n’est pas un serveur HTTP de production. Il peut le faire, mais il ne le fait pas bien.
• Le front mal sécurisé est une porte ouverte aux XSS, vols de sessions et clickjacking.
• Le back mal conçu expose des secrets, des injections, voire des accès shell.
• Un reverse proxy comme NGINX est ton premier pare-feu applicatif — et probablement le plus fiable si tu l’utilises correctement.
• Et qu’au final, sécuriser une app Node, ce n’est pas la cerise sur le gâteau. C’est la base du gâteau.

💥 Alors, c’est grave docteur ?

Pas encore. Mais tu sais ce qui l’est ?

• Un serveur Node qui expose une stack trace complète en prod.
• Un fichier .env commité dans un repo public.
• Un middleware JWT codé maison… sans vérification de signature.

Ces choses-là, elles arrivent tous les jours. Dans des apps utilisées. En entreprise. En production.
Et pas par des débutants. Par des gens pressés. Par des gens qui ont cliqué sur “Déployer” un vendredi à 17h.

🧠 Si tu devais retenir une chose :

Node.js n’est pas dangereux. Le laisser sans garde-fou, si.

Alors fais les choses bien :

• Ajoute un reverse proxy.
• Sépare les responsabilités.
• Code comme si quelqu’un allait tenter de t’exploiter demain.
• Parce qu’il y a de grandes chances que ce soit déjà le cas aujourd’hui.

🧰 Bonus pour ton prochain projet Node :

• Reverse proxy NGINX en place
• Headers HTTP de sécurité actifs
• Validation stricte des entrées
• Audit automatique des dépendances
• Logs nettoyés et structurés
• Monitoring en place
• Aucun accès direct au port Node depuis Internet

Si tu coches tout ça, tu peux dormir tranquille.
Sinon… prépare-toi à te lever à 3h du matin avec un Cannot GET / et un site remplacé par un drapeau turc.

💬 À toi de jouer : Tu as un projet Node exposé sans proxy ? Une lib douteuse dans ton package.json ? Un petit eval() oublié quelque part ?
Tu sais ce qu’il te reste à faire.

🦕 Et Deno dans tout ça ?

Oui, on sait. Il existe un cousin plus propre, plus moderne, plus sécurisé : Deno. Il embarque HTTPS, des permissions strictes, l’import par URL, et une philosophie “secure by default”.
Mais Deno, c’est un autre sujet. Et on va en parler. Promis.
(Spoiler : même lui ne remplace pas un vrai reverse proxy.)

Partager cet article : Twitter LinkedIn WhatsApp

🖋️ Publié sur SecuSlice.com