Quelqu'un peut-il expliquer la différence entre un HTTP-GET et un HTTP-POST ? Et pourquoi dit-on qu'un HTTP-POST est plus faible en termes de sécurité ?
Réponses
Trop de publicités?
Mike Weller
Points
28387
Dans une requête HTTP GET, les paires clé/valeur sont spécifiées dans l'URL :
http://server/something?value1=foo&value2=bar .
Dans une demande HTTP POST, les paires clé/valeur sont envoyées dans le cadre de la demande HTTP après les en-têtes. Par exemple :
POST /something HTTP/1.1
Host: server
Content-Length: 21
Content-Type: application/x-www-form-urlencoded
value1=foo&value2=barIl est difficile de dire si l'un est plus ou moins sûr que l'autre, mais les données HTTP POST ne sont pas visibles dans l'URL, et lorsqu'on soumet des données à un site web, un HTTP POST ne peut généralement être exécuté qu'à la suite d'une interaction avec l'utilisateur (par exemple en cliquant sur un bouton "Submit").
Cela signifie qu'un utilisateur ne peut pas être trompé en visitant une URL telle que http://server/update_profile?name=I_suck et les données sensibles ne sont pas exposées dans l'URL.
Vous pouvez également utiliser nonces et d'autres jetons anti-falsification avec les formulaires html (qui utilisent le POST) pour empêcher d'autres formes de falsification de requêtes intersites.
En général, POST doit être utilisé pour les demandes qui modifient potentiellement l'état du serveur, et GET doit être utilisé pour les opérations en lecture seule.
Brabster
Points
18764
El Spécification HTTP différencie POST et GET en fonction de leur intention :
GET est idempotent : il sert à obtenir une ressource, sans rien changer sur le serveur. Par conséquent, il devrait être parfaitement sûr de soumettre à nouveau une demande GET.
POST ne l'est pas : il sert à mettre à jour les informations sur le serveur. On ne peut donc pas supposer que l'on peut soumettre à nouveau la demande en toute sécurité. C'est pourquoi la plupart des navigateurs demandent une confirmation lorsque vous appuyez sur la touche de rafraîchissement d'une demande POST.
En termes de sécurité, aucune différence. POST est plus obscur, peut-être, mais c'est une chose très différente. La sécurité doit être ajoutée à une autre couche, par exemple SSL.
shihab_returns
Points
819
Quelques notes sur les demandes GET :
- Les requêtes GET peuvent être mises en cache
- Les requêtes GET restent dans l'historique du navigateur
- Les demandes GET peuvent être mises en signet
- Les requêtes GET ne doivent jamais être utilisées lorsqu'il s'agit de données sensibles.
- Les requêtes GET ont des restrictions de longueur
- Les requêtes GET doivent être utilisées uniquement pour récupérer des données.
Quelques notes sur les demandes POST :
- Les requêtes POST ne sont jamais mises en cache
- Les requêtes POST ne restent pas dans l'historique du navigateur.
- Les demandes POST ne peuvent pas être mises en signet
- Les requêtes POST n'ont aucune restriction sur la longueur des données
Brian Rasmussen
Points
68853
Je ne dirais pas que POST est plus ou moins sûr que GET. Il est vrai que les paramètres sont affichés comme faisant partie de l'URL lorsque l'on utilise GET, de sorte que toute donnée sensible sera immédiatement visible pour l'utilisateur. Cependant, il est trivial de visualiser et même de modifier n'importe quelle partie de la requête HTTP. Ainsi, même si POST ne transmet pas les données par l'intermédiaire de l'URL, elles peuvent être facilement lues. À moins que vous n'utilisiez le protocole HTTPS, GET et POST transfèrent les données sous une forme facilement accessible.
Gumbo
Points
279147
El Méthode GET est destiné à la recherche de données uniquement et ne devrait pas avoir d'effets secondaires . Mais POST est destiné à cette fin spécifique : modifier les données du côté du serveur.
Les demandes GET peuvent facilement être devancées (voir Falsification de requête intersite ) en plaçant simplement une image sur une page alors qu'il n'est pas si facile de falsifier des requêtes POST (c'est aussi une raison pour laquelle vous ne devriez autoriser que les requêtes POST autorisées).
