#Sécurité appliquée
La sécurité n’est pas une liste de vulnérabilités à mémoriser: c’est une façon de concevoir qui évite les classes de bugs et limite l’impact quand ils surviennent. On va poser un modèle de menace, puis appliquer des protections systématiques côté données (crypto), identité (auth), et surface Web. Contexte pédagogique: niveau L3 (Valrose — UCA), avec des démonstrations en lecture et des exercices d’analyse.
#Penser “modèle de menace” avant “checklist”
Qui vous attaque, que peut‑il faire, que protégez‑vous et avec quel budget d’effort ? Un site vitrine public n’a pas les mêmes enjeux qu’un coffre‑fort numérique. Cette clarification guide les priorités: ce qui doit être confidentiel, intègre, disponible.
#Menaces et contre‑mesures, racontées simplement
L’injection (SQL/NoSQL/commandes) arrive quand on mélange données et code. La défense: requêtes préparées, API paramétrées, et validation/assainissement d’entrée. Le XSS survient quand on réinjecte du contenu non fiabilisé dans du HTML: on encode/échappe systématiquement, on active une CSP stricte et on évite de rendre du HTML brut. Le CSRF exploite des actions authentifiées déclenchées à votre insu: on utilise des jetons synchronisés, des cookies SameSite et on exige le bon Origin/Referer.
L’authentification/autorisation s’appuie sur des standards modernes (OAuth2/OIDC) et des sessions sûres (cookies HttpOnly, Secure, rotation). La MFA réduit drastiquement la prise de contrôle de comptes.
#Hygiène continue
Gérer les secrets (ne pas committer, chiffrer au repos, rotation), journaliser et alerter (limitation de débit, IPs suspectes), maintenir à jour (dépendances, OS). Ce n’est pas glamour, mais c’est ce qui vous garde en bonne santé.
#Mini‑atelier
- Transformez une requête SQL construite par concaténation en requête préparée.
- Ajoutez un en‑tête CSP de base et constatez ce qui est bloqué.
- Durcissez un cookie de session (
HttpOnly,Secure,SameSite=Strict) et expliquez l’impact.