Authentification token & cookies sécurisés

Pourquoi sécuriser une API ?

Maintenant que tu sais manipuler Node.js, TypeScript, Hono et Prisma, tu es prêt à rendre ton API vraiment utile. Mais une question critique se pose : comment garantir que seuls les utilisateurs autorisés peuvent accéder aux fonctionnalités les plus sensibles (générer une image, consulter leur galerie, dépenser des crédits...) ?

C’est là qu’intervient le sujet de ce module : sécuriser ton API grâce à l’authentification ― sans t’arracher les cheveux, ni tomber dans les pièges classiques.
Le but : empêcher n’importe qui d’appeler tes routes privées, tout en offrant une expérience simple et robuste à tes utilisateurs.

Les limites du modèle public

Lorsqu’une API démarre, tout est ouvert par défaut : chaque requête GET ou POST reçoit une réponse, aucune distinction entre visiteur lambda et utilisateur identifié.
Concrètement : n’importe qui peut consommer les ressources, accéder à la base ou lancer des triggers sensibles.

Il te faut donc un mécanisme de verrouillage. En 2025, la norme, c’est l’authentification par token : chaque utilisateur authentifié reçoit un jeton (token), qu’il présente lors de ses appels suivants. Ce système est aussi utilisé par des API massives comme Replicate, Stripe ou Firebase.

Token d’authentification : principe

Au lieu de garder une session serveur, ici, le backend génère un token sécurisé lors de l’inscription ou du login. Ce token, stocké côté client (dans un cookie HTTPOnly et/ou LS), est renvoyé à chaque requête protégée :

1
const header = c.req.header("authorization")
2
if (!header) throw new HTTPException(401, { message: "Unauthorized" })
3
const token = header.split(" ")[1]
4
// ... vérifie dans la base si le token correspond à un user

Si le token est bon, la logique backend continue. Sinon, l’accès est refusé.
Aucun token côté client = accès bloqué.
Mauvais token = message d’erreur immédiat.

Sécurisation via cookies HTTPOnly

Bonus sécurité : tu peux stocker le token dans un cookie sécurisé (flag HttpOnly, Secure, SameSite).
De cette manière, aucune attaque front-end (type XSS) ne peut voler ce précieux sésame, et ton API filtre tout ce qui ne vient pas d’un utilisateur loggé.

Pour en savoir plus sur les cookies sécurisés :
MDN — Set-Cookie

Ce que tu vas apprendre dans ce module

Dans ce module, tu vas voir :

• Comment générer un token au moment de l’inscription ou de la connexion.
• Où et comment stocker ce token côté client (cookie sécurisé vs stockage local).
• Mettre en place un middleware Hono qui protège toutes les routes privées grâce au token.
• Comment rendre la gestion transparente pour l’utilisateur (connexion, déconnexion, rafraîchissement...).

Tu auras un code robuste, prêt à la mise en production, et aucun utilisateur ne pourra générer des images ou accéder à une galerie qui ne lui appartient pas.
On attaque ?