Les URL : pratiques mais dangereuses
Une URL est l'adresse d'une page web. Quand vous saisissez « google.com », c'est une URL ; « amazon.fr/products/laptop » en est une autre. C'est simplement l'adresse du site que vous voulez consulter.
Une URL se compose de plusieurs parties. Le protocole, d'abord : « https:// » signifie que l'échange est chiffré (sécurisé), « http:// » fait la même chose sans chiffrement (dangereux). Vient ensuite le domaine (« google.com »), puis le chemin (« /search »), puis les paramètres (« ?q=chat »). L'ensemble forme l'URL.
Les paramètres ont leur importance. Lors d'une recherche Google, l'URL devient « google.com/search?q=chat » : le « ?q=chat » indique « cherche le mot chat ». L'URL évolue selon l'action, ce qui est pratique : vous pouvez la partager, et votre interlocuteur verra exactement la même page.
C'est ainsi que fonctionne le web au fond : vous saisissez une adresse, le navigateur envoie une demande au serveur, le serveur lit l'adresse et répond avec la page. Simple. Mais voici le problème : beaucoup oublient qu'une URL est visible et modifiable. On peut la lire, la copier, la modifier. C'est là que naissent les risques de sécurité.
« Une URL n'est pas sécurisée : elle est visible et modifiable. Et c'est un vecteur d'attaque considérable. »
Imaginez le site d'une banque, avec l'URL « bank.com/account/12345 », où « 12345 » est votre numéro de compte. Si quelqu'un la remplace par « bank.com/account/67890 » et accède à un autre compte, c'est une faille : le site ne vérifie pas réellement votre droit d'accès. On parle de vulnérabilité de contrôle d'accès.
Il y a aussi l'injection SQL. Une URL peut contenir des paramètres malveillants, comme « site.com/search?q=chat OR 1=1 ». Si le site est mal sécurisé, il exécute cette requête sur la base de données, qui peut alors renvoyer toutes les données. C'est une attaque par injection.
Vient ensuite le XSS (Cross Site Scripting) : on peut glisser du JavaScript dans une URL, par exemple « site.com/search?q=<script>volerCookies()</script> ». Si le site affiche la recherche sans la nettoyer, le script s'exécute et peut voler les cookies de l'utilisateur.
Et puis il y a les données sensibles. Certains placent des mots de passe ou des jetons dans l'URL : « site.com/login?username=john&password=123456 ». C'est une aberration : l'URL apparaît dans l'historique du navigateur, dans les journaux du serveur, et à l'écran par-dessus votre épaule. Jamais de données sensibles dans une URL.
Un bon site ne place dans l'URL que des données non sensibles : des identifiants (12345), des paramètres de recherche (q=chat), des filtres (category=electronics). On n'y met jamais de mots de passe, de jetons d'authentification, de numéros de carte bancaire ni d'informations personnelles. C'est pourquoi les sites sérieux emploient la méthode « POST » plutôt que « GET » : « GET » place les données dans l'URL, « POST » les met dans le corps de la requête, invisible. Pour des données sensibles, on utilise POST, et l'on valide et nettoie toujours tout ce qui provient de l'URL avant de s'en servir.