2.1Formulaires & superglobales ($_GET, $_POST)
L'essentiel en 30 secondes
- GET lit, POST modifie : GET expose les données dans l'URL (recherche, filtres, liens partageables) ; POST les envoie dans le corps (inscription, connexion, données sensibles) — jamais de mot de passe en GET.
- Ne jamais faire confiance aux entrées : toute donnée reçue est potentiellement erronée ou malveillante — validation serveur obligatoire, la validation JavaScript ne suffit jamais.
- Valider puis assainir selon le contexte : filter_var vérifie le format, htmlspecialchars protège l'affichage, les requêtes préparées protègent la base — un outil par usage.
Mini-cas filé — Riad et le formulaire d'inscription à Constantine
Riad, développeur web à Constantine, crée le formulaire d'inscription d'une association locale : nom, e-mail, wilaya. Sa première version affiche directement ce que l'utilisateur tape — un test avec un script dans le champ nom casse la page. Il reconstruit le traitement en trois temps : récupérer via $_POST, valider côté serveur (champ requis, e-mail valide avec filter_var), échapper avec htmlspecialchars avant tout affichage. Ce même chantier revient en 2.2 (garder l'utilisateur connecté en session), 2.3 (factoriser le formulaire par inclusions) et 2.4 (valider l'e-mail et dater l'inscription).
Fil conducteur du niveau 2 : ce même chantier de Riad revient dans le cours, le schéma, le script et le défi 48h — et continue en 2.2, 2.3 et 2.4.
1. $_GET et $_POST : deux méthodes, deux usages
Une application web INTERAGIT avec l'utilisateur, surtout via des formulaires. Quand le formulaire est soumis, les données partent au serveur et PHP les RÉCUPÈRE grâce aux superglobales — des tableaux spéciaux disponibles partout dans le code. La méthode GET passe les données dans l'URL (la « query string » : recherche.php?q=chaise) : elles sont VISIBLES, historisées, partageables et mises en favori — idéale pour LIRE (recherche, filtre, pagination, tri), car la requête est idempotente (la recharger ne change rien). PHP les lit dans $_GET ($_GET['q']). La méthode POST passe les données dans le CORPS de la requête (invisibles dans l'URL) : idéale pour CRÉER/MODIFIER (inscription, connexion, commande) et pour les données sensibles ou volumineuses. PHP les lit dans $_POST. Le formulaire HTML déclare la méthode (method='post') et la cible (action : le fichier PHP qui traite). Riad l'applique : sa recherche d'adhérents part en GET (URL partageable), son inscription part en POST. D'autres superglobales existent : $_FILES (uploads, section 2.3), $_SERVER (infos requête), $_SESSION/$_COOKIE (section 2.2). À éviter : $_REQUEST, qui mélange GET et POST et manque de précision.
2. Ne jamais faire confiance aux entrées
Le réflexe fondamental du développeur web : ne JAMAIS faire confiance aux données reçues. Tout ce qui vient du client (formulaire, URL, en-tête) est potentiellement ERRONÉ ou MALVEILLANT : un utilisateur peut désactiver JavaScript, modifier le code dans son navigateur, ou envoyer des requêtes forgées directement au serveur sans jamais passer par votre page. La validation côté client (JavaScript) sert l'EXPÉRIENCE (retour immédiat, guidage) mais elle est contournable ; la validation côté serveur (PHP) sert la SÉCURITÉ et elle est obligatoire — c'est la seule que vous contrôlez. Riad en a fait l'expérience : son contrôle JavaScript « champ requis » n'a rien bloqué quand un testeur a envoyé le formulaire vide via un outil direct. Règle : on re-vérifie TOUT côté serveur, toujours.
3. Valider, puis assainir selon le contexte
Le traitement serveur tient en deux gestes. Valider : vérifier que les données ont le format attendu (champ requis rempli ? e-mail valide ? nombre positif ?) et rejeter/signaler sinon — PHP aide avec filter_var() (e-mail, URL, entier…). Assainir/échapper : traiter les données selon l'usage qui en est fait — htmlspecialchars() avant d'AFFICHER (contre le XSS, qui injecte du HTML/JavaScript dans vos pages), requêtes préparées avant de mettre en BASE (contre l'injection SQL, niveau 3). Un outil par contexte, jamais l'inverse. Le formulaire de Riad valide donc l'e-mail avec filter_var($email, FILTER_VALIDATE_EMAIL) puis affiche le nom avec htmlspecialchars($nom) — systématiquement, sans exception.
🔎 Exemple concret — 🔎 Exemple concret — L'inscription de Riad, validée côté serveur
Le premier rempart, comme dans le formulaire de Riad :
$nom = trim($_POST['nom'] ?? '');
$email = trim($_POST['email'] ?? '');
if ($nom === '' || !filter_var($email, FILTER_VALIDATE_EMAIL)) {
echo 'Inscription invalide.';
} else {
echo 'Merci ' . htmlspecialchars($nom, ENT_QUOTES, 'UTF-8') . ' !';
}Lecture : récupération via $_POST, validation du format, échappement avant affichage.
Leçon : la validation JavaScript ne suffit JAMAIS — le serveur re-vérifie tout.
Vocabulaire de la section
- Formulaire / superglobales
- Les formulaires envoient des données au serveur, que PHP récupère via des superglobales, tableaux spéciaux disponibles partout : $_GET, $_POST, $_FILES, $_SESSION…
Exemple simple : Riad lit le nom saisi avec $_POST['nom'].
Ce que ce n'est pas : des variables ordinaires limitées à une fonction.
Réflexe : donnée venue du client = superglobale + méfiance.
- $_GET vs $_POST
- GET : données dans l'URL, visibles et partageables, pour lire (recherche, filtres). POST : données dans le corps, non visibles dans l'URL, pour modifier ou pour les données sensibles.
Exemple simple : La recherche de Riad part en GET, son inscription en POST.
Ce que ce n'est pas : deux syntaxes interchangeables sans conséquence.
Réflexe : lire = GET ; modifier ou sensible = POST.
- Ne jamais faire confiance aux entrées
- Toute donnée utilisateur est potentiellement erronée ou malveillante ; toujours valider et assainir côté SERVEUR avant de l'utiliser.
Exemple simple : Riad re-vérifie l'e-mail côté serveur même avec un contrôle JavaScript.
Ce que ce n'est pas : une donnée affichée telle quelle parce qu'elle vient de son propre formulaire.
Réflexe : entrée reçue = entrée suspecte jusqu'à validation.
- Valider
- Vérifier que les données ont le format attendu (requis rempli, e-mail valide, nombre correct) et rejeter sinon ; filter_var() aide pour e-mail, URL, entier.
Exemple simple : filter_var($email, FILTER_VALIDATE_EMAIL) accepte ou rejette l'inscription.
Ce que ce n'est pas : afficher la donnée en espérant qu'elle soit correcte.
Réflexe : chaque champ = une règle de validation explicite.
- Validation serveur obligatoire
- La validation client (JavaScript) améliore l'expérience mais est contournable ; la validation serveur (PHP) est obligatoire car c'est la seule fiable.
Exemple simple : Le testeur de Riad contourne le JavaScript, le PHP bloque quand même.
Ce que ce n'est pas : un contrôle JavaScript considéré comme une protection.
Réflexe : confort côté client, sécurité côté serveur.
En pratique — En pratique — Recevoir et traiter des données de formulaire
- Créez un formulaire HTML (method='post', action vers un fichier PHP) et récupérez les données côté serveur via $_POST['champ'].
- Comparez GET et POST : un formulaire de recherche en GET (données dans l'URL) vs un formulaire d'inscription en POST (corps, non visible).
- VALIDEZ les données côté serveur : champ requis rempli ? e-mail valide (filter_var) ? nombre correct ? — rejetez/signalez si invalide.
- ASSAINISSEZ : échappez avec htmlspecialchars() avant d'afficher des données utilisateur — et retenez que la validation client (JS) ne suffit JAMAIS.
Script prêt à dire — expliquer la double validation à un collègue (30 s)
« Pour le formulaire d'inscription, je garde le contrôle JavaScript pour le confort — retour immédiat. Mais je re-vérifie tout en PHP : champ requis, e-mail avec filter_var, et htmlspecialchars avant d'afficher. Le JavaScript se contourne en deux clics, le PHP c'est le seul endroit que je contrôle vraiment. »
À dire en montrant une requête forgée qui contourne le JavaScript mais se fait bloquer par le PHP.
Modèle copier-coller — traitement de formulaire sûr
' . htmlspecialchars($e, ENT_QUOTES, 'UTF-8') . '';
}
return;
}
echo 'Merci ' . htmlspecialchars($nom, ENT_QUOTES, 'UTF-8')
. ' (' . htmlspecialchars($email, ENT_QUOTES, 'UTF-8') . ') !
';Recherche partageable
Le catalogue de Riad se filtre en GET : l'URL contient les critères, on la partage et on la met en favori.
Inscription sensible
Nom, e-mail et mot de passe partent en POST : rien dans l'URL, rien dans l'historique — puis HTTPS pour le transport.
Liste blanche de valeurs
La wilaya vient d'une liste fermée : Riad vérifie que la valeur reçue appartient aux choix autorisés, sinon rejet.
Formulaire volumineux
Message long, plusieurs champs : POST accepte plus de données que GET, limité par la longueur de l'URL.
✓ Bonnes pratiques
- GET pour lire (recherche, filtre) ; POST pour modifier ou pour les données sensibles.
- Valider systématiquement côté serveur (filter_var, vérifications explicites).
- Échapper avec htmlspecialchars avant d'afficher la moindre donnée utilisateur.
✗ Pièges fréquents
- Se reposer sur la validation JavaScript (contournable en deux clics).
- Passer un mot de passe en GET (visible dans l'URL, l'historique, les logs).
- Utiliser $_REQUEST (mélange GET/POST, moins précis et moins sûr).
Points clés à retenir
- Les FORMULAIRES envoient des données que PHP récupère via des SUPERGLOBALES : $_GET (URL, recherches/filtres) et $_POST (corps, formulaires qui modifient/données sensibles).
- RÉFLEXE FONDAMENTAL : ne JAMAIS faire confiance aux données utilisateur (potentiellement erronées ou malveillantes) — toujours VALIDER et ASSAINIR côté SERVEUR avant usage.
- VALIDER (format attendu : e-mail, nombre, requis — filter_var) et ASSAINIR/ÉCHAPPER selon le contexte (htmlspecialchars avant d'afficher, requêtes préparées avant la base).
- La validation CÔTÉ CLIENT (JavaScript) améliore l'expérience mais est CONTOURNABLE ; la validation CÔTÉ SERVEUR (PHP) est OBLIGATOIRE — c'est elle qui protège réellement.
Défi 48h — appliquez demain
Prenez un vrai formulaire (le vôtre ou celui de Riad : nom + e-mail) et ajoutez le traitement serveur complet : récupération via $_POST, validation (requis + filter_var), affichage avec htmlspecialchars systématique. Puis contournez votre propre JavaScript et vérifiez que le PHP bloque.
- Je peux expliquer quand utiliser GET et quand utiliser POST, avec un exemple de chacun.
- Je sais valider côté serveur (requis, filter_var) et échapper avant affichage.
- J'ai testé qu'une requête forgée ne passe pas mon traitement serveur.
Questions fréquentes
GET ou POST : comment choisir la bonne méthode pour un formulaire ?
Selon la nature de l'action et la sensibilité des données. GET : données ajoutées à l'URL (visibles, historisées, partageables, mises en favori). POST : données dans le corps (pas dans l'URL). Règle : utilisez GET pour LIRE/RÉCUPÉRER (recherche, filtre, pagination, tri, lien) — la requête est idempotente (rechargeable sans risque) et l'URL partageable. Utilisez POST pour CRÉER/MODIFIER/SUPPRIMER (inscription, connexion, envoi, commande) — ces actions ne doivent pas se refaire par accident au rechargement (le navigateur prévient avant de renvoyer des données POST), les données ne polluent pas l'URL, et POST accepte plus de données. Données SENSIBLES (mot de passe) → POST, jamais GET — mais POST seul ne chiffre rien : il faut HTTPS pour la vraie confidentialité (POST évite l'exposition dans l'URL, HTTPS protège le transport). Les formulaires HTML ne supportent nativement que GET et POST ; les API (section 4-4) utilisent aussi PUT/PATCH/DELETE.
Pourquoi la validation côté serveur est-elle obligatoire si je valide déjà côté client (JavaScript) ?
Parce que le client n'est PAS fiable. La validation CLIENT (JavaScript) sert l'EXPÉRIENCE : retour immédiat, guidage — utile mais facilement CONTOURNABLE : JavaScript désactivé (validation ignorée), code modifié via les outils du navigateur, ou requête envoyée DIRECTEMENT au serveur (outil ou script) sans jamais passer par votre page. Rien ne garantit qu'une requête reçue vient de votre formulaire. La validation SERVEUR (PHP) sert la SÉCURITÉ : c'est le seul endroit fiable, que VOUS contrôlez. Sans elle : données corrompues, bugs, et FAILLES (injection SQL, XSS). Faites les deux : client pour le confort (souhaitable), serveur pour la sécurité (impératif) — re-vérifiez TOUT (requis, formats, longueurs, valeurs autorisées) et assainissez selon l'usage. Image : la validation client est un panneau poli, la validation serveur est le contrôle réel.
La validation côté client (JavaScript) suffit-elle pour la sécurité ?