Defending APIs

1Le test A-B prouve qu'un utilisateur ne lit pas l'objet d'un autre

Première famille : le code. Le livre suit le Top 10 des failles d'API de l'OWASP (Open Worldwide Application Security Project). En tête vient le BOLA (Broken Object Level Authorization) : l'utilisateur connecté change le numéro dans l'URL et lit le reçu d'un autre client.

Le remède : autoriser « chaque accès à un objet, sans exception » (leçon 19). Le BOLA a un cousin, le BFLA (Broken Function Level Authorization) : être connecté n'ouvre pas les fonctions d'administration.

La preuve : le test A-B. L'utilisateur A crée une ressource, l'utilisateur B tente d'y accéder. « Si vous y arrivez, vous avez un problème d'autorisation » (leçon 49). L'auteur conseille d'écrire ces tests soi-même, mais n'en montre aucun (leçon 63).

2Trois objets distincts ferment la porte au mass assignment

L'autorisation dit qui touche à un objet, pas quels champs l'API accepte. Le mass assignment (affectation en masse) naît d'un raccourci : le framework copie tous les champs reçus vers la base. L'attaquant ajoute "is_admin": true, et l'API l'enregistre.

La parade du livre tient en trois objets (leçon 65) :

• L'objet d'entrée : ce que le client peut envoyer.
• L'objet de base : ce qui est stocké, mot de passe haché compris.
• L'objet de sortie : ce que le client peut lire.

Pour l'auteur, la plupart des failles de données viennent d'un passage direct entre objets « sans considérer la sensibilité des données » (leçon 65). Ma traduction en Go, pas celle du livre (en Python) :

type UserIn struct { // ce que le client peut envoyer
	Email    string `json:"email"`
	Password string `json:"password"`
}

type UserInDB struct { // ce qui est stocké
	Email        string
	PasswordHash string
	IsAdmin      bool
}

type UserOut struct { // ce que le client peut lire
	Email string `json:"email"`
}

func createUser(w http.ResponseWriter, r *http.Request) {
	var in UserIn
	if err := json.NewDecoder(r.Body).Decode(&in); err != nil {
		http.Error(w, "requête invalide", http.StatusBadRequest)
		return
	}
	// un "is_admin" envoyé n'a nulle part où aller : UserIn n'a pas ce champ
	db := UserInDB{Email: in.Email, PasswordHash: hashPassword(in.Password)}
	save(db)
	json.NewEncoder(w).Encode(UserOut{Email: db.Email}) // ni hash ni rôle
}
// hashPassword (argon2id ou bcrypt) et save : non montrés

Le décodage ne remplit que UserIn. Le passage vers UserInDB est écrit à la main, hachage compris, comme dans le livre. Rien ne sort sans place dans UserOut.

3Le contrat OpenAPI devient une règle que l'intégration continue fait respecter

Ces objets se décrivent aussi dans un contrat OpenAPI, le format standard des routes, champs, types et limites d'une API. Pour le livre, « la définition est le contrat, tout ce qui n'est pas dans le contrat est invalide » (leçon 55).

Un audit repère ce qui reste ouvert, comme un entier sans maximum. Le contrat exige l'authentification partout, puis la relâche route par route : une route oubliée reste fermée (leçon 56).

Cet audit tourne dans l'intégration continue (CI), la chaîne qui teste chaque modification avant la fusion, et un défaut grave peut casser le build. L'outil doit rester rapide, « idéalement moins d'une minute » (leçon 58).

4Un JWT se vérifie avec l'algorithme du serveur, jamais avec celui du jeton

Un piège échappe à l'audit du contrat : le JWT (JSON Web Token), un jeton signé qui porte l'identité de l'utilisateur. En CI, Semgrep, un outil qui cherche des motifs dans le code, repère un jeton décodé sans vérifier sa signature (leçon 58). Or l'en-tête du JWT annonce l'algorithme, et c'est le client qui l'écrit.

L'attaquant peut y écrire none, « pas de signature », ou signer en symétrique avec la clé publique du serveur (leçons 47 et 48). Une bibliothèque qui suit l'en-tête accepte alors son faux jeton.

La parade : « soyez explicite sur l'algorithme et la clé utilisés, et ignorez les valeurs fournies dans l'en-tête du JWT » (leçon 60).

5À la passerelle, le client ne voit jamais le vrai jeton

Seconde famille : l'API en ligne. La passerelle d'API (API gateway) reçoit les appels extérieurs et les route vers les services. Or un JWT est signé, pas chiffré : son destinataire le lit.

Un JWT colle trois parties : en-tête, contenu, signature. Le livre décrit deux façons de cacher le contenu (leçon 86) :

• Le jeton opaque (phantom token) : le client ne reçoit qu'une référence, échangée à chaque appel contre le vrai JWT, au prix de calcul et d'« un point de défaillance unique et central ».
• Le split token (jeton coupé en deux) : le client ne reçoit que la signature, et la passerelle retrouve le jeton entier en cache (moins de goulot, selon l'auteur).

Aucun code, et rien sur la révocation d'un jeton déjà émis (leçon 86).

6Entre deux services, le mTLS va de soi

La passerelle protège en général le trafic nord-sud, pas le trafic ouest-est, celui qui circule entre les services (leçon 80). Pour celui-là, le livre pose le mTLS (mutual TLS). TLS chiffre HTTPS. En mode mutuel, client et serveur présentent chacun un certificat et vérifient celui de l'autre.

Sa conclusion : le mTLS « doit être considéré comme acquis dans tout déploiement de microservices » (leçon 84). Rien sur la rotation, la révocation ou le lien jeton-certificat.