Les données envoyées via HTTP POST sont-elles cachées ou plus sûres que via GET ?
Réponse courte
Non. POST place simplement les paramètres dans le corps de la requête au lieu de l'URL ; ce corps est en clair et parfaitement visible pour quiconque voit le trafic, sauf en HTTPS. POST est préférable pour les actions qui modifient l'état et garde les paramètres hors des URL, des journaux et de l'historique, mais il n'offre aucune confidentialité en soi. L'erreur confond « pas dans l'URL » et « chiffré » — seul TLS chiffre les données de l'une ou l'autre méthode en transit.
Un nombre surprenant de développeurs croient que POST « cache » les données. Il ne chiffre rien. Comprendre pourquoi teste clairement la distinction entre transport et chiffrement.
Pourquoi la réponse populaire est fausse
Sur le réseau, une requête POST ressemble à ceci : ligne de requête, en-têtes, une ligne vide, puis le corps contenant vos paramètres — sous forme de texte lisible. Une requête GET place ces paramètres dans la chaîne de requête de l'URL à la place. Dans les deux cas, si la connexion est en HTTP simple, quiconque observe le trafic — un renifleur réseau, un point Wi-Fi malveillant, un proxy transparent — lit directement les valeurs. POST change où se trouve la donnée, pas si elle est chiffrée. Affirmer que POST est « chiffré » ou que ses paramètres sont « secrets pour les proxys » parce qu'ils ne sont pas journalisés est tout simplement faux ; un proxy qui termine ou inspecte la connexion voit tout le corps.
Ce que POST vous apporte réellement
POST a de vrais atouts, mais pas la confidentialité. Comme les paramètres ne sont pas dans l'URL, ils ne finissent pas dans l'historique du navigateur, les journaux d'accès du serveur, les favoris ou l'en-tête Referer envoyé à des tiers — autant d'endroits où une chaîne de requête GET peut fuiter. POST est aussi la méthode correcte pour les actions qui modifient l'état (elle n'est ni sûre ni idempotente) et évite les limites de longueur d'URL. De bonnes raisons de l'utiliser, mais d'hygiène et de sémantique, pas de cryptographie.
La vraie solution : TLS
La seule chose qui rend l'une ou l'autre requête confidentielle est HTTPS / TLS, qui chiffre toute la requête — méthode, en-têtes, URL et corps — entre le navigateur et le serveur. Sous TLS, les corps GET et POST sont protégés des espions sur le chemin. Même alors, préférez POST pour les secrets, car une URL d'une requête GET peut encore apparaître dans les journaux et l'historique après déchiffrement. Le résumé prêt pour l'entretien : POST sort la donnée de l'URL ; TLS la rend secrète. Confondre les deux est le piège.
Questions de suivi probables
- Qu'est-ce qui chiffre réellement le corps POST en transit, et à quelle couche ?
- Pourquoi envoyer un mot de passe dans une chaîne de requête GET reste-t-il une mauvaise idée en HTTPS ?
- Où les paramètres GET peuvent-ils fuiter là où les paramètres POST ne le font pas ?