Sécurité

Stockage des mots de passe

Les mots de passe sont hachés avec bcrypt (cost factor 12). Les mots de passe en clair ne sont jamais stockés, même temporairement en mémoire serveur — ils sont supprimés immédiatement après le hachage. Lors de l'inscription, les mots de passe sont vérifiés via l'API Have I Been Pwned, et les mots de passe ayant un historique de fuite connu sont rejetés.

Jetons et sessions

Les jetons d'authentification sont des JWT signés avec l'algorithme HS256. En production, un secret JWT d'au moins 32 caractères est requis — le serveur ne démarrera pas sans.

Les jetons de rafraîchissement sont hachés avec bcrypt (cost factor 10) avant stockage. Ils font l'objet d'une rotation à chaque utilisation — chaque rafraîchissement émet un nouveau jeton et invalide le précédent. Les TTL des deux types de jetons sont configurables par projet.

Les sessions sont gérées côté serveur avec l'adresse IP, le user agent et l'horodatage de dernière activité. Les utilisateurs peuvent consulter les sessions actives et révoquer des sessions individuelles ou toutes les sessions depuis le tableau de bord.

Authentification multifacteur

L'authentification multifacteur basée sur TOTP est prise en charge. Les secrets TOTP sont chiffrés avec AES avant stockage. 10 codes de secours sont générés par utilisateur, chacun haché avec HMAC-SHA256. La vérification des codes de secours utilise une comparaison en temps constant pour prévenir les attaques temporelles.

OAuth et connexion sociale

Les paramètres d'état OAuth sont générés avec crypto.randomBytes(32) pour prévenir les attaques CSRF. 20 fournisseurs OAuth sont pris en charge, et les URL de callback sont limitées par projet.

Passkeys (WebAuthn)

L'authentification par passkeys repose sur la norme FIDO2/WebAuthn. La vérification côté serveur utilise la bibliothèque SimpleWebAuthn.

Sécurité réseau

Toutes les communications sont chiffrées via TLS. HSTS (HTTP Strict Transport Security) est appliqué avec un max-age d'1 an.

CORS est configuré avec une liste blanche dynamique qui n'autorise que les domaines enregistrés pour chaque projet. Les origines joker ne sont pas utilisées.

Le serveur API utilise le middleware Helmet pour définir les en-têtes de sécurité incluant Content-Security-Policy, X-Frame-Options (DENY) et X-Content-Type-Options (nosniff).

Protection contre la force brute

Les tentatives de connexion échouées sont enregistrées par utilisateur. Par défaut, les comptes sont verrouillés pendant 300 secondes (5 minutes) après 5 tentatives échouées. Ces seuils sont configurables dans les paramètres de sécurité de chaque projet. Une connexion réussie réinitialise le compteur d'échecs.

Cloudflare Turnstile CAPTCHA peut être activé par projet, ajoutant des défis de protection contre les bots aux flux d'inscription et de connexion.

Validation des entrées

Toutes les entrées API sont validées avec class-validator. Les champs non reconnus sont automatiquement supprimés (mode whitelist), et les requêtes contenant des champs explicitement interdits sont rejetées. Les mots de passe nécessitent un minimum de 8 caractères. Les requêtes en base de données utilisent des requêtes paramétrées TypeORM pour prévenir l'injection SQL.

Sécurité des Webhooks

Chaque endpoint webhook se voit attribuer un secret de signature unique à sa création. Les payloads webhook sont signés avec HMAC-SHA256, livrés avec un horodatage dans l'en-tête X-Authon-Signature. Les livraisons échouées sont automatiquement réessayées jusqu'à 3 fois.

Signaler des vulnérabilités

Si vous découvrez une vulnérabilité de sécurité, veuillez la signaler à security@authon.dev. N'ouvrez pas d'issue publique — contactez-nous directement par e-mail.