Durcissement applicatif

Prérequis : cours 2.x (injections, XSS, CSRF) ; DevOps 8.1 (hardening serveur).

Pourquoi

Le serveur durci ne sert à rien si l'app accepte tout : le durcissement applicatif, c'est les garde-fous par défaut dans le code — validation, erreurs sobres, uploads verrouillés, admin cloisonnée.

Concepts

• Validation : allowlist (formats connus) > denylist (liste noire toujours incomplète). Côté serveur toujours (le client se contourne en 2 clics). Limites de taille partout (body, fichiers, JSON imbriqué — billion laughs !).
• Erreurs sobres : à l'user = message générique + id de corrélation ; stack traces = logs serveur uniquement. Une pile d'erreur offerte = cartographie gratuite (versions, chemins, SQL !).
• Uploads : type réel vérifié (pas l'extension !), taille plafonnée, stockage hors webroot (jamais d'exécution dans le dossier d'upload), antivirus/scan si sensibles, noms aléatoires (pas de ../../).
• Admin : route séparée, 2FA obligatoire, rate-limit agressif, IP allowlist si possible, logs dédiés. L'admin est la cible n°1 : la traiter comme telle.

Exemple : upload sûr (conceptuel)

1. Taille ≤ 5 Mo refusée sinon 2. Type magique vérifié (pas extension)
3. Nom aléatoire, dossier hors webroot, sans exec 4. Servi via URLs signées à expiry

Cas réel

Avatar SVG uploadé sans vérification : <svg onload=…> = XSS stockée sur tous les profils (cf. 2.2). Correctif : rasterisation côté serveur (SVG→PNG) + CSP. Un upload = une exécution potentielle.

Pièges

• Validation client seule : DevTools contourne tout. Serveur toujours.
• Messages d'erreur verbeux (« Unknown column users.ssn ») : de la reco offerte. Générique + id.
• Billion laughs (entités XML gigognes) : limite de taille ≠ protection. Parser durci + quotas.

À retenir

Allowlist serveur, erreurs sobres + id, uploads hors webroot vérifiés, admin 2FA + cloisonnée.