Sécurité

Protégez les secrets (MISTRAL_API_KEY, AUTH_SECRET).
Paramétrez CORS, rôles, et permissions (RBAC).
Surveillez les dépendances et appliquez des mises à jour régulières.

Hachage des mots de passe

Par défaut, Better Auth utilise l’algorithme scrypt (mémoire-dur et résistant au brute-force).
Vous pouvez personnaliser le hachage via la config password (hash/verify) dans apps/server/src/lib/auth.ts si besoin.

Gestion des sessions

Expiration et rafraîchissement

Config actuelle dans auth.ts : maxAge: 86400 (24h), updateAge: 3600 (1h).
À chaque utilisation, si updateAge est atteint, l’expiration est prolongée.

Révocation

Better Auth permet la révocation des sessions (déconnexion côté serveur). Prévoyez des actions UI pour permettre aux utilisateurs de se déconnecter des autres appareils.

Protection CSRF

Better Auth valide l’en-tête Origin. Les origines de confiance sont définies via trustedOrigins dans auth.ts.
Côté Hono (apps/server/src/index.ts), CORS est configuré avec credentials: true et une validation stricte d’origine incluant CORS_ORIGIN.

OAuth : State et PKCE (Microsoft)

Pour Microsoft OAuth, Better Auth persiste state et PKCE pendant le flux afin d’éviter CSRF et injections de code.
Nettoyage après finalisation du flux.

Cookies

Better Auth émet des cookies sécurisés si https est utilisé.
Attributs : httpOnly activé, sameSite par défaut lax.
Pour multi-sous-domaines, utilisez l’option crossSubDomainCookies si nécessaire.

Personnalisation

Personnalisez les noms/options des cookies pour réduire le fingerprinting et répondre aux contraintes d’infra (proxy/ingress).

Limitation de débit (Rate limiting)

Better Auth applique un rate limiting de base sur ses routes. En prod, complétez via votre proxy/ingress (ex: NGINX, Cloudflare) pour une défense en profondeur.

Adresse IP et en-têtes

Par défaut, Better Auth lit X-Forwarded-For.
Vous pouvez spécifier des en-têtes IP de confiance dans la config avancée, p. ex. :

// apps/server/src/lib/auth.ts
betterAuth({
  advanced: {
    ipAddress: {
      ipAddressHeaders: ["cf-connecting-ip"],
    },
  },
});

Veillez à ce que votre proxy charge bien cet en-tête et qu’il ne soit pas contrôlable par les clients.

Origines de confiance

Définissez précisément les origines de confiance pour bloquer CSRF et redirections ouvertes :

trustedOrigins: [
  "https://example.com",
  "https://app.example.com",
  "http://localhost:3001", // front en dev
]

Les jokers (*.example.com) sont acceptés, avec nuances selon le protocole.

Bonnes pratiques projet

Secrets : stockez AUTH_SECRET, RESEND_API_KEY, MISTRAL_API_KEY, MICROSOFT_CLIENT_ID/SECRET/TENANT_ID dans apps/server/.env (jamais en clair dans le repo).
CORS : définissez CORS_ORIGIN (front exact, schéma+host+port). Gardez credentials: true côté client (ORPC) pour inclure les cookies.
HTTPS en prod : requis pour cookies secure.
RBAC : utilisez les procédures protectedProcedure/adminProcedure (voir apps/server/src/lib/orpc.ts) et validez le rôle depuis le plugin admin.
Observabilité : surveillez /health et /ready, alertez sur pics de 401/403/429.

Signalement de vulnérabilités

Si vous suspectez une faille, ouvrez un ticket interne ou contactez l’équipe responsable de la sécurité. Décrivez le scénario d’attaque, l’impact et, si possible, un correctif proposé.

Security Considerations