Examen niveau 2 — PHP · GUIDINEE.COM

Examen — questions inédites

12 questions inédites : rappel (25 %) + application (50 %) + arbitrage (25 %) sur PHP & le Web.
Répondez à tout, puis cliquez sur Corriger : score et explications s'affichent.

2.1 · Rappel

1. Que contiennent $_GET et $_POST ?

Les fichiers du serveur Les journaux d'erreurs PHP Les données envoyées en GET (URL) et en POST (corps), récupérées côté serveur Les préférences du navigateur

GET : données dans l'URL ; POST : données dans le corps — lues via les superglobales.

2.1 · Application

2. Riad affiche le nom saisi dans son formulaire. Quelle ligne est sûre ?

echo stripslashes($_POST['nom']); echo '' . $_POST['nom'] . ''; echo $_POST['nom']; echo htmlspecialchars($_POST['nom'] ?? '', ENT_QUOTES, 'UTF-8');

htmlspecialchars neutralise le HTML/JavaScript injecté : l'affichage reste du texte.

2.1 · Arbitrage

3. Un collègue affirme que sa validation JavaScript suffit et veut supprimer les contrôles PHP. Verdict de Riad ?

À refuser : le client est contournable, seule la validation serveur protège À remplacer par des captures d'écran du formulaire À accepter : le JavaScript couvre tous les cas À accepter pour les petits formulaires uniquement

JavaScript désactivé, code modifié ou requête forgée : le client ne protège jamais.

2.2 · Rappel

4. Quelle est la différence entre un cookie et une session ?

Le cookie nécessite une base de données, la session non Le cookie stocke les données côté client (modifiables), la session côté serveur (sûres) Aucune, ce sont deux noms pour la même chose La session expire immédiatement, le cookie jamais

Données de confiance en session (serveur) ; préférences non sensibles en cookie.

2.2 · Application

5. Riad code la connexion des adhérents. Quel enchaînement est correct ?

Mettre l'identifiant dans un cookie modifiable Comparer avec md5 sans session Stocker le mot de passe en clair puis comparer les chaînes password_verify sur le hash, session_regenerate_id, puis $_SESSION['user_id']

Vérification sur le hash, ID régénéré contre la fixation, identité côté serveur.

2.2 · Arbitrage

6. Un adhérent change l'id dans l'URL et voit les données d'un autre. Quelle règle manquait ?

L'autorisation : vérifier le DROIT sur cette ressource, pas juste la connexion Aucune, c'est un usage normal Un cookie supplémentaire Une police plus grande

Connecté ne veut pas dire autorisé : chaque ressource contrôle son accès.

2.3 · Application

7. Riad factorise son menu dupliqué dans dix pages. Que fait-il ?

Il supprime le menu du site Il crée header.php une fois et l'inclut par require dans chaque page Il inclut include $_GET['page'] sans contrôle Il recopie le menu une onzième fois par sécurité

Écrire une fois, inclure partout : une modification à un seul endroit.

2.3 · Application

8. Riad reçoit une photo d'événement via $_FILES. Quelle pratique est correcte ?

Stocker dans un dossier où PHP s'exécute pour prévisualiser Faire confiance à l'extension déclarée Vérifier le type réel et la taille, renommer, stocker sans exécution PHP Garder le nom d'origine et l'afficher aussitôt

Upload = entrée hostile : type réel, renommage, stockage sans exécution.

2.3 · Arbitrage

9. Un collègue propose include $_GET['page'] pour charger les pages dynamiquement. Verdict ?

À remplacer par plus de copier-coller À accepter : c'est la méthode recommandée À accepter avec un joli thème À refuser : inclusion de fichier arbitraire — ne jamais inclure un chemin utilisateur sans contrôle strict

Un chemin utilisateur inclus sans contrôle laisse l'attaquant charger des fichiers arbitraires.

2.4 · Rappel

10. Comment stocker et afficher une date correctement ?

Stocker au format ISO (AAAA-MM-JJ) et formater seulement à l'affichage Stocker 25/07/2026 et afficher tel quel Stocker le nom du jour en toutes lettres Ne jamais stocker de dates

ISO : triable, non ambigu, standard en base ; le format local n'est qu'un affichage.

2.4 · Application

11. Riad doit valider l'e-mail d'un nouvel adhérent. Que choisit-il ?

Aucune validation, le champ est optionnel filter_var($email, FILTER_VALIDATE_EMAIL) — plus fiable Une regex maison copiée sans test Un contrôle de longueur uniquement

Cas courant = filtre éprouvé ; regex réservée aux motifs métier spécifiques.

2.4 · Application

12. La lettre d'information doit partir à 500 adhérents. Quelle solution ?

Des données utilisateur injectées dans les en-têtes La fonction mail() basique en boucle Une bibliothèque dédiée (PHPMailer, Symfony Mailer) avec SMTP authentifié Des e-mails tapés à la main un par un

Bibliothèque dédiée : authentification, pièces jointes, délivrabilité — en-têtes verrouillés.

Et après ?

Score ≥ 80 % : passez au Niveau 3 — bases de données (PDO, requêtes préparées) et programmation orientée objet, sur les bases web acquises ici.
Score 60-79 % : reprenez les sections ratées (2.1 validation serveur, 2.2 sessions, 2.3 inclusions/uploads, 2.4 DateTime/filter_var) et refaites les défis 48h.
Score < 60 % : reconstruisez le chantier de Riad pas à pas (formulaire validé, connexion en session, site factorisé, dates et e-mails), puis repassez le test.
Dans tous les cas : gardez les réflexes web — ne jamais faire confiance aux entrées, htmlspecialchars avant d'afficher, mots de passe hachés, uploads traités comme hostiles.