Le choix entre GET et POST dépend de la NATURE de l'action (lire vs modifier) et de la sensibilité des données — voici la règle claire. Rappel des différences techniques : (1) GET : les données sont ajoutées à l'URL (la « query string » : recherche.php?q=chaise&categorie=meuble). Elles sont donc VISIBLES dans l'URL, dans l'historique du navigateur, les logs serveur, et peuvent être mises en FAVORI ou partagées (l'URL contient tout). (2) POST : les données sont dans le CORPS de la requête (pas dans l'URL). Elles ne sont pas visibles dans l'URL, pas dans l'historique, pas mises en favori. La règle de choix (basée sur la sémantique HTTP, déjà vue) : (1) Utilisez GET pour LIRE / RÉCUPÉRER (actions sans effet de bord). Quand l'action ne fait que RÉCUPÉRER de l'information, sans rien modifier sur le serveur : une recherche, un filtre, une pagination, un tri, un lien vers une page. GET convient car : (a) la requête est IDEMPOTENTE (la refaire ne change rien — on peut recharger la page sans risque) ; (b) l'URL contient les paramètres, donc on peut la PARTAGER, la METTRE EN FAVORI (une recherche partageable), la recharger. Exemple : un formulaire de recherche → GET (l'URL ?q=chaise est partageable, rechargeable). (2) Utilisez POST pour CRÉER / MODIFIER / SUPPRIMER (actions avec effet de bord). Quand l'action MODIFIE quelque chose sur le serveur (créer un compte, envoyer un message, se connecter, passer une commande, supprimer) : POST. Raisons : (a) ces actions ne doivent pas être IDEMPOTENTES par accident (recharger une page qui a envoyé un POST redemande confirmation — le navigateur prévient « voulez-vous renvoyer les données ? » pour éviter de refaire l'action, ex. commander deux fois) ; (b) les données ne polluent pas l'URL (pas de favori/historique avec des données de formulaire) ; (c) POST accepte plus de données (GET est limité par la longueur de l'URL). (3) Données SENSIBLES → POST (jamais GET). Un mot de passe, des données personnelles ne doivent PAS passer par GET (donc pas dans l'URL, qui est visible, historisée, loguée). Utilisez POST. MAIS attention : POST n'est PAS chiffré en soi — pour la vraie confidentialité, il faut HTTPS (qui chiffre toute la communication). POST évite juste l'exposition dans l'URL ; HTTPS protège le transport. Les deux vont ensemble pour les données sensibles. (4) Données VOLUMINEUSES → POST (GET est limité par la taille de l'URL). Le principe sémantique (important) : GET pour les requêtes qui LISENT (sûres, idempotentes, partageables) ; POST pour celles qui MODIFIENT (effet de bord, non partageables, avec confirmation au rechargement). Respecter cette sémantique n'est pas qu'une convention — cela évite des bugs (recharger et refaire une action par accident) et respecte le fonctionnement du web (favoris, historique, cache, boutons précédent/suivant). Exemples concrets : (1) Recherche de produits → GET (partageable, rechargeable, lit seulement). (2) Formulaire d'inscription → POST (crée un compte, données sensibles). (3) Connexion (login) → POST (mot de passe sensible, crée une session). (4) Filtres d'une liste → GET (lit, partageable). (5) Ajout au panier / commande → POST (modifie). (6) Formulaire de contact → POST (envoie un message). Note sur les autres méthodes : pour les API (section 4-4), on utilise aussi PUT, PATCH, DELETE (modifier, supprimer) — mais les formulaires HTML classiques ne supportent nativement que GET et POST (les frameworks contournent cela). En résumé : GET pour LIRE/récupérer (recherche, filtre, pagination — sûr, idempotent, partageable, données non sensibles dans l'URL) ; POST pour CRÉER/MODIFIER (inscription, connexion, envoi, commande — effet de bord, données sensibles ou volumineuses hors de l'URL). Le critère : l'action LIT-elle ou MODIFIE-t-elle ? Les données sont-elles sensibles ? Respecter cette sémantique HTTP évite des bugs et respecte le fonctionnement du web. Et rappelez-vous : POST cache les données de l'URL mais ne les chiffre pas — pour la sécurité réelle, HTTPS est indispensable (surtout pour les données sensibles). Choisir la bonne méthode est un fondamental du développement web, cohérent avec les principes HTTP.

C'est une règle de sécurité ABSOLUE et non négociable : la validation côté client (JavaScript) ne remplace JAMAIS la validation côté serveur (PHP), parce que le client n'est PAS fiable — comprendre pourquoi vous protège d'une faille majeure. Les deux validations, leurs rôles : (1) Validation côté CLIENT (JavaScript, dans le navigateur) : vérifie les données AVANT l'envoi, dans le navigateur. Son rôle est l'EXPÉRIENCE UTILISATEUR : donner un retour IMMÉDIAT (« cet email est invalide », « ce champ est requis ») sans attendre un aller-retour serveur, guider l'utilisateur, éviter des soumissions inutiles. C'est UTILE et RECOMMANDÉ pour le confort. (2) Validation côté SERVEUR (PHP) : vérifie les données APRÈS réception, sur le serveur. Son rôle est la SÉCURITÉ et l'INTÉGRITÉ : garantir que les données sont valides et sûres avant de les utiliser (les mettre en base, les traiter). Pourquoi la validation CLIENT NE SUFFIT PAS (le point crucial) : la validation côté client est FACILEMENT CONTOURNABLE, car le client (navigateur) est sous le contrôle de l'UTILISATEUR, pas de vous. Un utilisateur (surtout malveillant) peut : (1) DÉSACTIVER JavaScript dans son navigateur → toute votre validation JavaScript est ignorée, les données arrivent brutes au serveur. (2) MODIFIER le JavaScript (via les outils de développement du navigateur) → contourner ou altérer les validations. (3) ENVOYER des requêtes DIRECTEMENT au serveur (sans passer par votre page/formulaire du tout) → avec des outils (curl, Postman, scripts), un attaquant envoie exactement ce qu'il veut à votre serveur, sans jamais exécuter votre JavaScript. C'est le point clé : votre serveur reçoit des requêtes, et RIEN ne garantit qu'elles viennent de votre formulaire avec sa validation JavaScript. Une requête peut être forgée de toutes pièces. Conséquence : si vous vous reposez UNIQUEMENT sur la validation client, un attaquant (ou même un bug côté client) peut envoyer des données INVALIDES ou MALVEILLANTES à votre serveur, qui les traitera comme valides → données corrompues, bugs, et surtout FAILLES DE SÉCURITÉ (injection SQL, XSS, données malformées exploitées). C'est une porte ouverte. Le principe fondamental : « ne jamais faire confiance au client / aux entrées ». Tout ce qui vient de l'extérieur (le navigateur, l'utilisateur) est potentiellement malveillant et doit être vérifié CÔTÉ SERVEUR, où VOUS avez le contrôle. Le serveur est votre dernière ligne de défense — il DOIT valider, car c'est le seul endroit fiable. Comment faire correctement (les deux ensemble) : (1) Validez côté CLIENT pour l'EXPÉRIENCE (retour immédiat, confort) — c'est un plus. (2) Validez côté SERVEUR pour la SÉCURITÉ — c'est OBLIGATOIRE et non négociable. Re-vérifiez TOUT côté serveur : champs requis, formats (email, nombre), longueurs, valeurs autorisées, cohérence. Ne supposez JAMAIS que les données sont valides parce que le client était censé les valider. (3) La validation serveur est la VRAIE validation ; la validation client est du confort par-dessus. Si vous ne deviez en faire qu'une, ce serait la validation SERVEUR (la sécurité prime sur le confort). En pratique, faites les deux : serveur pour la sécurité (impératif), client pour l'expérience (souhaitable). Ce que la validation serveur doit couvrir : (1) VALIDER : format, présence, longueur, valeurs autorisées, cohérence des données. (2) ASSAINIR/ÉCHAPPER selon l'usage : htmlspecialchars avant d'afficher (XSS), requêtes préparées avant la base (injection SQL), etc. (3) Rejeter proprement les données invalides (message d'erreur, code approprié). Une image : la validation client est comme un panneau « merci d'essuyer vos pieds » à l'entrée (poli, incite au bon comportement, mais n'empêche personne d'entrer avec des chaussures sales) ; la validation serveur est le videur qui contrôle réellement à la porte (personne ne passe sans être vérifié). Vous avez besoin du videur (serveur), le panneau (client) est un plus. En résumé : la validation côté serveur est OBLIGATOIRE parce que le client (navigateur, JavaScript) n'est PAS fiable — un utilisateur peut désactiver/modifier le JavaScript ou envoyer des requêtes directement au serveur, contournant toute validation client. La validation client sert le CONFORT (retour immédiat) ; la validation serveur sert la SÉCURITÉ (elle seule protège réellement). Faites les deux, mais ne comptez JAMAIS sur le client pour la sécurité. « Ne jamais faire confiance aux entrées » est le réflexe fondamental du développeur web — la validation serveur systématique en est l'application directe. Négliger cela ouvre des failles graves ; l'appliquer est le premier rempart de toute application web sûre.