Traiter un formulaire PHP POST semble simple : on récupère $_POST et on fait “le truc”. En réalité, c’est là que commencent les failles (XSS), les erreurs utilisateur mal gérées et les doublons de soumission. Dans ce tutoriel, vous allez construire une base propre : validation côté serveur, messages d’erreur clairs, réaffichage des valeurs, et un flux de traitement robuste.

1) Comment fonctionne un formulaire PHP en POST

Un formulaire PHP POST envoie les données dans le corps de la requête HTTP. Contrairement à GET, les informations ne sont pas visibles dans l’URL, ce qui est plus adapté pour des données sensibles (mot de passe, email) ou des actions qui modifient l’état de l’application.

PHP récupère ces données dans la superglobale $_POST. En bref : si le formulaire est soumis en POST, vous lirez vos champs dans $_POST["nom_du_champ"].

Info : même si vous validez en JavaScript, la validation serveur reste obligatoire. Un utilisateur (ou un bot) peut envoyer un POST sans passer par votre page.

2) Structure HTML correcte du formulaire

Voici un formulaire minimal et correct :

[html]<form method= »POST » action= » »>
<label for= »email »>Email</label>
<input id= »email » type= »email » name= »email » required>

<label for= »password »>Mot de passe</label>
<input id= »password » type= »password » name= »password » required>

<button type= »submit »>Envoyer</button>
</form>[/html]

Points importants :

method= »POST » : indispensable si vous voulez utiliser $_POST.

name= »… » : c’est la clé utilisée dans $_POST.

required : utile pour l’UX, mais ne remplace jamais la validation serveur.

3) Récupérer les données avec $_POST

La base propre : on vérifie la méthode HTTP, puis on lit les champs avec un fallback. Ça évite les notices et ça rend le code robuste.

[php]$email = »;
$password = »;
$errors = [];

if ($_SERVER[‘REQUEST_METHOD’] === ‘POST’) {
$email = $_POST[’email’] ?? »;
$password = $_POST[‘password’] ?? »;
}[/php]

Bonne pratique : initialisez vos variables (valeurs + erreurs) avant le traitement. Comme ça, le template peut toujours afficher quelque chose, même sans soumission.

4) Validation des champs en PHP

La validation d’un formulaire PHP POST doit répondre à 2 questions : “est-ce présent ?” et “est-ce valide ?”. On stocke les erreurs dans un tableau associatif par champ, ce qui simplifie l’affichage.

[php]$errors = [];

if ($_SERVER[‘REQUEST_METHOD’] === ‘POST’) {

// Normalisation simple
$email = trim($email);

// Email obligatoire
if ($email === ») {
$errors[’email’] = « L’email est obligatoire. »;
} elseif (!filter_var($email, FILTER_VALIDATE_EMAIL)) {
$errors[’email’] = « Email invalide. »;
}

// Mot de passe : exemple de règle simple
if ($password === ») {
$errors[‘password’] = « Le mot de passe est obligatoire. »;
} elseif (strlen($password) < 8) {
$errors[‘password’] = « Mot de passe trop court (8 caractères minimum). »;
}
}[/php]

Vous pouvez ajouter d’autres règles (caractères spéciaux, complexité, etc.) selon le contexte. Mais gardez la validation lisible.

Note : valider = refuser si invalide. Échapper = protéger l’affichage. Ce sont deux sujets différents. Vous devez faire les deux.

5) Afficher les erreurs proprement

Objectif : afficher une erreur près du champ concerné et réafficher la valeur saisie (sauf mot de passe). Pour réafficher, on échappe toujours avec htmlspecialchars().

Exemple de formulaire avec erreurs + réaffichage

[html]<form method= »POST » action= » »>

<label for= »email »>Email</label>
<input id= »email » type= »email » name= »email » value= »<?= htmlspecialchars($email ?? », ENT_QUOTES, ‘UTF-8’) ?> »>
<?php if (!empty($errors[’email’])): ?>
<p style= »color:red;margin:6px 0 0; »><?= htmlspecialchars($errors[’email’], ENT_QUOTES, ‘UTF-8’) ?></p>
<?php endif; ?>

<label for= »password » style= »margin-top:12px;display:block; »>Mot de passe</label>
<input id= »password » type= »password » name= »password »>
<?php if (!empty($errors[‘password’])): ?>
<p style= »color:red;margin:6px 0 0; »><?= htmlspecialchars($errors[‘password’], ENT_QUOTES, ‘UTF-8’) ?></p>
<?php endif; ?>

<button type= »submit » style= »margin-top:12px; »>Envoyer</button>
</form>[/html]

Attention : ne réaffichez jamais une valeur utilisateur sans htmlspecialchars(). Sinon, vous ouvrez la porte au XSS.

6) Sécuriser un formulaire PHP (XSS)

Un formulaire est une surface d’attaque. Le XSS arrive souvent quand on affiche une donnée utilisateur sans échappement. La règle : tout ce qui vient de l’utilisateur est suspect.

Bon :

[php]echo htmlspecialchars($email, ENT_QUOTES, ‘UTF-8’);[/php]

Mauvais :

[php]echo $email;[/php]

Info : même si vous “validez” l’email, vous devez toujours échapper à l’affichage. La validation ne garantit pas l’absence de problème dans tous les contextes (attribut HTML, texte, JS, etc.).

7) Pattern POST → Redirect → GET

Après un POST valide, la bonne pratique est de rediriger vers une page GET. Ça évite la double soumission (refresh du navigateur) et ça rend le flux propre.

[php]if ($_SERVER[‘REQUEST_METHOD’] === ‘POST’) {

// … validations …

if (empty($errors)) {
// Ici : traitement (ex : sauvegarde en BDD)

// Redirection après succès
header(‘Location: success.php’);
exit;
}
}[/php]

Bonne pratique : ajoutez un message de succès via session (flash message) si vous voulez afficher “Compte créé” après la redirection.

8) Erreurs fréquentes

Ne pas vérifier la méthode ($_SERVER['REQUEST_METHOD']) et traiter $_POST en permanence.

Valider uniquement en JavaScript : contournable en 2 secondes.

Afficher des valeurs non échappées : XSS.

Réafficher le mot de passe dans la valeur d’un input : mauvaise pratique.

Oublier le PRG : double soumission au refresh.

Questions fréquentes

POST ou GET pour un formulaire PHP ?

Utilisez POST pour les données sensibles et toutes les actions qui modifient quelque chose (création, mise à jour, suppression). GET est plutôt adapté à la recherche et aux pages partageables.

Pourquoi valider côté serveur si j’ai déjà du JavaScript ?

Parce qu’un utilisateur peut désactiver JS ou envoyer une requête HTTP directement. La validation JS améliore l’UX, la validation PHP protège votre application.

Comment éviter la double soumission d’un formulaire ?

Avec le pattern POST → Redirect → GET : vous traitez le POST, puis vous redirigez. Un refresh ne renverra pas le POST.

Comment protéger un formulaire contre le XSS ?

En échappant systématiquement les données utilisateur à l’affichage avec htmlspecialchars() (et en évitant d’afficher du contenu brut dans le HTML).

Est-ce que $_POST est “sécurisé” ?

Non. $_POST contient des données envoyées par le client. Vous devez toujours valider, normaliser et sécuriser avant d’utiliser ces valeurs (affichage, BDD, logique métier).

Conclusion

Traiter un formulaire PHP POST proprement, c’est : vérifier la méthode, récupérer les données proprement, valider côté serveur, afficher des erreurs par champ, échapper à l’affichage pour éviter le XSS, et terminer par une redirection (PRG) quand tout est OK. C’est une base simple, mais c’est la différence entre un code fragile et un code pro.

Pour aller plus loin :

PDO : insérer en base avec requêtes préparées

Sessions PHP : messages flash et authentification

Protection CSRF : token de formulaire (indispensable sur les actions sensibles)

GET vs POST : lequel choisir et pourquoi

Objectif : comprendre en profondeur la différence entre GET vs POST en PHP, savoir quand utiliser chaque méthode HTTP selon le contexte (SEO, sécurité, logique métier, API) et éviter les erreurs d’architecture fréquentes. Choisir entre GET et POST en PHP…

PDO en PHP : connexion + requêtes préparées (anti-injection SQL)

Sommaire Connexion propre à MySQL avec PDOSELECT avec requête préparéeINSERT sécurisé UPDATE Pourquoi les requêtes préparées protègent de l’injection SQL Gérer les erreurs : dev vs prod Exemple complet minimal fonctionnel Erreurs fréquentes Conclusion 1) Connexion propre à MySQL avec…

Formulaire PHP POST : validation propre + gestion erreurs