J aimerai savoir quelle est la plus securiser en get ou post ?
Merci
la communauté d'entraide francophone dédiée au PHP
Get ou Post
POST sera plus sécurisé parce que les données ne sont pas affichées comme avec GET dans l'url et donc non manipulable. Avec GET en effet, rien n'empèche un internaute de modifier manuellement une url pour envoyer des paramètres bidons dans un but qui pourrait éventuellement se révéler malveillant.
Mais si tu précises davantage ta question, tu auras peut-être une réponse plus appropriée.
Mais si tu précises davantage ta question, tu auras peut-être une réponse plus appropriée.
Codez en pensant que celui qui maintiendra votre code est un psychopathe qui connait votre adresse 
L'avantage de l a méthode GET, c'est qu'elle dispense de l'utilisation d'un formulaire, mais comme je l'expliquais plus haut, elle permet à l'internaute d'envoyer des paramètres bidons en modifiant manuellement l'url dans la barre d'adresse de son navigateur.Quels sont les points avantages de ces 2 options ?
La méthode POST en revanche ne permet pas cette manipulation et ne fonctionne qu'à partir d'un formulaire.
Ce qui est important, c'est de choisir en fonction du traitement qui doit être fait avec les données envoyées. Si les données doivent donner lieu à un échange avec une base de données, on évitera la méthode GET pour court-circuiter les possibilités d'injection SQL et de piratage. Mais pour afficher des pages dans un système de pseudo-frame par exemple, on peut parfaitement utiliser la méthode GET : index.php?page=accueil, index.php?page=nouvelles, etc...
J'ajoute enfin que la méthode GET est limitée : une url ne peut excéder une certaine longueur et il ne sera pas possible d'utiliser la méthode GET avec un gros formulaire si l'ensemble des données représente une quantité de caractères supérieure à 500 à 800 selon le navigateur.
Dernier point : les urls paramétrées sont moins bien référencées dans les moteurs de recherche et Google par exemple n'indexe pas les pages qui comportent plus de trois paramètres.
Codez en pensant que celui qui maintiendra votre code est un psychopathe qui connait votre adresse
C'est un peu plus compliqué que de juste changer les paramètre dans l'url avec la méthode POST, mais ce n'est pas pour autant qu'on ne peut pas trafiquer les valeurs envoyées. Ce n'est pas à la porter du premier venu certes, mais c'est possible et il vaut mieux toujours contrôler les paramètres "sensibles" que tu reçois que tu sois en GET ou POST.La méthode POST en revanche ne permet pas cette manipulation et ne fonctionne qu'à partir d'un formulaire.
L'une des différences nottoire également entre GET et POST c'est que comme toutes les données sont présentes dans l'url en GET, tu peux actualiser, faire des précédents/suivants, etc. sur ta page, les données sont "repostées" automatiquement pour afficher la page.
En POST, le navigateur te demandera une confirmation pour renvoyer les données du formulaire.
A voir ensuite si la page afit des insert, il vaut mieux éviter de renvoyer les données en appuyant juste sur F5. S'il s'agit juste d'un affichage (comme sur ce forum), c'est plus agréable de pas avoir à confirmer à chaque fois quand on accède à une page
A voir également le pattern "PRG" (Post - Redirect - Get) consistant à récupérer les données en Post, faire le traitement demandé, et Rediriger l'utilisateur vers une page en Get pour gérer cela
Ryle +1
On se satisfait souvent de la sécurité illusoire de la méthode POST car on pense que comme on ne voit pas les variables dans l'url, celles-si sont sécurisées. Loin s'en faut. Elle sont, tout comme par GET, transmises en clair. De plus, on peut facilement simuler l'envoi d'un formulaire en transmettant le header approprié par sockets ou, plus facilement encore, avec CURL.
POST est, il est vrai, un peu plus confidentiel dans le sens où par GET, il suffirait de se pencher au dessus de l'épaule d'un utilisateur pour lui piquer son mot de passe.
Juste pour illustrer le problème de transmettre des données sensibles par GET ou POST, voici un petit exemple:
Voici un bête formulaire de deux champs:
Voici les trames (facilement) capturées (ici par tcpdump):
POST /test/aaa.php HTTP/1.1
User-Agent: Opera/9.01
Host: debian
Accept: text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/jpeg, image/gif, image/x-xbitmap, */*1
Accept-Language: fr,fr-BE;q=0.9,en;q=0.8
Accept-Charset: iso-8859-1, utf-8, utf-16, *;q=0.1
Accept-Encoding: deflate, gzip, x-gzip, identity, *;q=0
Referer: http://debian/test/test.php
Connection: Keep-Alive, TE
TE: deflate, gzip, chunked, identity, trailers
Content-Length: 215
Content-Type: multipart/form-data; boundary=----------I1w1EgLcZsSZT5bxg4igvI
------------I1w1EgLcZsSZT5bxg4igvI
Content-Disposition: form-data; name="nom"
moi
------------I1w1EgLcZsSZT5bxg4igvI
Content-Disposition: form-data; name="pass"
hello
-----------I1w1EgLcZsSZT5bxg4igvI--
Si, vraiment, c'est la sécurité qui compte --> SSL
On se satisfait souvent de la sécurité illusoire de la méthode POST car on pense que comme on ne voit pas les variables dans l'url, celles-si sont sécurisées. Loin s'en faut. Elle sont, tout comme par GET, transmises en clair. De plus, on peut facilement simuler l'envoi d'un formulaire en transmettant le header approprié par sockets ou, plus facilement encore, avec CURL.
POST est, il est vrai, un peu plus confidentiel dans le sens où par GET, il suffirait de se pencher au dessus de l'épaule d'un utilisateur pour lui piquer son mot de passe.
Juste pour illustrer le problème de transmettre des données sensibles par GET ou POST, voici un petit exemple:
Voici un bête formulaire de deux champs:
Code : Tout sélectionner
<form method="POST" action="aaa.php">
<input type="text" name="nom" /><br />
<input type="password" name="pass" /><br />
<input type="submit" value="Envoyer" />
</form>POST /test/aaa.php HTTP/1.1
User-Agent: Opera/9.01
Host: debian
Accept: text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/jpeg, image/gif, image/x-xbitmap, */*1
Accept-Language: fr,fr-BE;q=0.9,en;q=0.8
Accept-Charset: iso-8859-1, utf-8, utf-16, *;q=0.1
Accept-Encoding: deflate, gzip, x-gzip, identity, *;q=0
Referer: http://debian/test/test.php
Connection: Keep-Alive, TE
TE: deflate, gzip, chunked, identity, trailers
Content-Length: 215
Content-Type: multipart/form-data; boundary=----------I1w1EgLcZsSZT5bxg4igvI
------------I1w1EgLcZsSZT5bxg4igvI
Content-Disposition: form-data; name="nom"
moi
------------I1w1EgLcZsSZT5bxg4igvI
Content-Disposition: form-data; name="pass"
hello
-----------I1w1EgLcZsSZT5bxg4igvI--
Si, vraiment, c'est la sécurité qui compte --> SSL
ripat