HTTP et le web
Requête, réponse, état — ce que suppose acquis tout cours de sécurité web.
HTTP est un protocole texte, en question-réponse. Le client envoie une requête, le serveur renvoie une réponse, et la connexion ne garde aucun souvenir. Toute la complexité du web vient de cette dernière propriété.
GET /profil HTTP/1.1
Host: exemple.fr
Cookie: session=8f3k9q2e
User-Agent: curl/8.5.0Trois éléments : une méthode (GET), une cible (/profil), des
en-têtes. Une requête avec corps — POST, PUT — ajoute une ligne vide puis
les données.
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Set-Cookie: session=8f3k9q2e; HttpOnly; Secure; SameSite=LaxLe code de statut annonce la nature de la réponse
| Famille | Sens | Exemples |
|---|---|---|
2xx | succès | 200 OK, 201 Created, 204 No Content |
3xx | redirection | 301 permanente, 302 temporaire, 304 non modifié |
4xx | le client a tort | 400, 401 non authentifié, 403 interdit, 404 |
5xx | le serveur a tort | 500, 502, 503 |
La confusion 401 / 403 est constante : 401 signifie « je ne sais pas qui tu
es », 403 « je sais qui tu es, et tu n'as pas le droit ». La première invite à
s'authentifier, la seconde non.
Sans état, donc avec cookies
Le serveur ne reconnaît pas les connexions successives. Pour qu'une session existe, il émet un identifiant que le navigateur renvoie à chaque requête :
- l'utilisateur s'authentifie ;
- le serveur crée une session côté serveur et renvoie
Set-Cookie: session=…; - le navigateur joint ce cookie à toutes les requêtes suivantes vers ce domaine ;
- le serveur retrouve la session à partir de cet identifiant.
Trois attributs décident de la sûreté du procédé. HttpOnly interdit la lecture
du cookie par JavaScript — sans lui, une faille d'injection de script suffit à
voler la session. Secure interdit son envoi en clair. SameSite limite son
envoi lors des requêtes venues d'un autre site.
Tout ce qui vient du client est manipulable
Méthode, chemin, paramètres, corps, et tous les en-têtes : rien de ce qui
arrive au serveur n'est digne de confiance. User-Agent, Referer,
X-Forwarded-For s'écrivent en une ligne de curl. Un contrôle d'accès qui
s'appuie sur un en-tête, ou une validation faite uniquement dans le navigateur,
ne protège de rien : la requête peut être forgée sans passer par la page.
Le piège classique
GET est réputé sans effet de bord, POST réputé modifier. Ce n'est qu'une
convention : rien n'empêche d'écrire une suppression derrière un GET. Mais
tout l'écosystème la suppose — les navigateurs préchargent les GET, les proxys
les mettent en cache, les moteurs les explorent. Une action destructrice derrière
un GET/supprimer?id=42 finit exécutée par un robot d'indexation.
Autre confusion utile à lever : HTTPS chiffre le transport. Il garantit que personne ne lit ni ne modifie la conversation en chemin, et que le serveur est bien celui annoncé. Il ne dit rien de la qualité de l'application : un site en HTTPS peut être vulnérable de bout en bout.
Réponse unique
Quelle est la différence entre un statut 401 et un 403 ?
Indice · L'un des deux invite à s'authentifier, l'autre non.
[ METTRE EN PRATIQUE ]
Observer une conversation HTTP
3 étapes · 25 min · 110 XP
[ CETTE LEÇON DANS LES PARCOURS ]
- Fondamentauxétape 16 / 18suivant — Réseau et analyse de trafic →