Security

Déconnectez un utilisateur d’une application basée sur les sessions, et le serveur l’oublie dès la requête suivante. Déconnectez-le d’une application basée sur JWT et, à moins d’avoir mis en place un mécanisme supplémentaire, le token qu’il détient reste valide jusqu’à son expiration. Cette différence est la vraie décision derrière « JWT contre session ». Tout le reste en découle. Ce qu’une session stocke réellement Une session garde l’état de l’utilisateur sur le serveur et ne transmet au navigateur qu’une clé de référence. ...

Un endpoint de login vous renvoie un JWT, et vous avez trois endroits où le stocker : un cookie, localStorage, ou sessionStorage. Faites le mauvais choix et soit une faille XSS embarque le token avec elle, soit le token n’arrive jamais jusqu’à votre API. Les trois stockent des chaînes de caractères dans le navigateur. Ce qui change, c’est qui peut les lire, combien de temps elles survivent, et si le serveur les voit un jour. ...

Votre frontend tourne sur http://localhost:5173, votre API sur http://localhost:4000, et l’appel fetch qui fonctionnait sans problème dans Postman échoue dans le navigateur avec un mur de texte rouge : Access to fetch at 'http://localhost:4000/api/users' from origin 'http://localhost:5173' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Votre serveur a très bien pu traiter cette requête et renvoyer un 200. Le navigateur, lui, a refusé de transmettre la réponse à votre JavaScript. ...

Comment atteindre une base de données qui n’écoute que sur localhost ? Une instance Postgres sur un serveur distant est liée à 127.0.0.1 volontairement. Rien sur le réseau ne peut l’atteindre, seuls les processus qui tournent sur cette même machine le peuvent. Votre ordinateur portable n’est pas cette machine, donc psql -h remote-server -p 5432 échoue avant même d’arriver à l’authentification. Ouvrir le port au monde entier annulerait la raison même pour laquelle il a été lié au loopback. ...

Ce que TLS protège vraiment sur une connexion HTTPS Chargez une page en http:// en clair sur un réseau que vous ne contrôlez pas, un aéroport ou le routeur d’un café, et tout ce que vous envoyez circule en texte lisible. Le chemin de l’URL, les cookies, les champs du formulaire, le mot de passe dans un POST de connexion : n’importe qui sur ce réseau avec un sniffer de paquets les lit au passage. TLS, Transport Layer Security, est le protocole qui bloque cela. Il se place entre TCP et le protocole applicatif, si bien que quand HTTP commence à parler, la connexion est déjà chiffrée et rattachée à une identité serveur vérifiée. HTTPS, c’est HTTP exécuté sur cette connexion au lieu d’une connexion en clair. ...

Où finissent les variables d’environnement d’un conteneur Démarrez un conteneur avec -e DB_PASSWORD=hunter2 et lancez docker inspect dessus : 1 2 docker run -d --name api -e DB_PASSWORD=hunter2 nginx:alpine docker inspect --format '{{json .Config.Env}}' api 1 ["DB_PASSWORD=hunter2","PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"] Le mot de passe reste là en clair, lisible par quiconque a accès au socket Docker, par docker exec api env, et par n’importe quel processus qui tourne dans le conteneur. Ce n’est pas un bug : c’est exactement à ça que servent les variables d’environnement. Le problème, c’est de les utiliser pour des valeurs qui ne devraient jamais être aussi visibles. ...