hariri.ch
Prenez contact

En 1 minute ~1 min de lecture

404 ou 403 dans une API : quand cacher une ressource

Votre API dit-elle trop de choses avec ses codes d’erreur ? Quand une ressource ne doit pas être visible, 404 est souvent plus utile que 403.

Diagramme en deux colonnes comparant 403 et 404. La colonne 403 montre une ressource connue, puis une vérification d’autorisation, puis un refus d’accès. La colonne 404 montre une ressource non visible pour ce client, puis une réponse 404 pour ne pas confirmer son existence.
Le schéma montre quand 403 révèle une ressource existante et quand 404 évite de confirmer son existence.

403 signifie que le serveur a compris la requête mais refuse l’accès. 404 signifie que la ressource n’est pas trouvée.

La différence utile, côté API, est la suivante : un 403 confirme implicitement que la ressource existe. Un 404 peut être préférable quand révéler cette existence serait déjà une fuite d’information. Le bon choix dépend donc du modèle d’accès et de ce que le client est censé savoir.

Exemple concret : sur GET /users/123/invoices/987, si l’utilisateur ne doit jamais savoir que la facture 987 existe, renvoyer 404 évite de confirmer sa présence. En revanche, si la ressource est connue mais qu’une opération précise est interdite, par exemple DELETE, 403 est généralement plus clair.

Règle pratique : 403 pour un refus explicite, 404 quand l’existence même de la ressource doit rester cachée.