#Sécurité appliquéeCopier le lien

La sécurité n'est pas une liste de vulnérabilités à mémoriser: c'est une façon de concevoir qui évite des classes entières de bugs et limite l'impact quand ils surviennent. On commence par un modèle de menace, puis on empile des protections systématiques sur trois niveaux: les primitives cryptographiques, les protocoles qui les composent, et la sécurité applicative du logiciel lui-même. Contexte pédagogique: L3 (Valrose, UCA), lectures guidées et exercices d'analyse avec pistes de correction.

Prérequis

• Bases de Python et du Web client/serveur (module reseaux-web).
• Notions de systèmes d'exploitation: processus, mémoire, fichiers.
• Représentations binaire et hexadécimale, opération XOR.

Objectifs d'apprentissage

• Distinguer primitive cryptographique, protocole et sécurité applicative, et situer une panne de sécurité au bon niveau.
• Construire un modèle de menace minimal: actifs, attaquants, surfaces d'attaque, conséquences.
• Reconnaître les grandes classes de failles applicatives (injection, XSS, CSRF, défauts d'authentification) et leurs contre-mesures standard.

#Trois niveaux à ne pas confondreCopier le lien

Beaucoup de failles réelles viennent d'une confusion de niveaux: une primitive correcte assemblée dans un protocole bancal, ou un protocole solide derrière une application qui laisse fuir ses secrets.

La règle pratique: une primitive ne devient sûre qu'une fois correctement composée, et un protocole sûr ne survit pas à une application qui l'utilise mal. En cas d'incident, identifier le niveau fautif évite de « réparer » au mauvais endroit, par exemple en changeant d'algorithme de chiffrement alors que la faille était une injection SQL.

#Penser « modèle de menace » avant « checklist »Copier le lien

Qui vous attaque, que peut-il faire, que protégez-vous et quel budget d'effort accordez-vous à la défense ? Un site vitrine public n'a pas les mêmes enjeux qu'un coffre-fort numérique. Cette clarification détermine ce qui doit être confidentiel, intègre, disponible. La section « Principes et modèle de menace » détaille la méthode (STRIDE, moindre privilège, défense en profondeur).

#Menaces applicatives et contre-mesuresCopier le lien

L'injection (SQL, NoSQL, commandes) survient quand on mélange données et code. La défense: requêtes préparées, API paramétrées, validation côté serveur. Le XSS survient quand on réinjecte du contenu non fiabilisé dans du HTML: on échappe systématiquement selon le contexte, 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: jetons synchronisés, cookies SameSite et vérification de l'en-tête Origin.

L'authentification et l'autorisation s'appuient sur des standards (OAuth 2.1/OpenID Connect) et des sessions durcies (cookies HttpOnly, Secure, rotation après login). La MFA réduit fortement la prise de contrôle de comptes. La section « Authentification Web » développe chaque mécanisme avec du code observable.

#Hygiène continueCopier le lien

Gestion des secrets (jamais dans le dépôt, chiffrés au repos, rotation), journalisation et alertes (taux d'échecs de login, limitation de débit), maintien en condition (dépendances, OS, CVE). Ce n'est pas spectaculaire, mais c'est ce qui maintient un système sain dans la durée. La section « Ressources » pointe vers OWASP et les outils de vérification.

#Mini-atelierCopier le lien

1. Transformez une requête SQL construite par concaténation en requête préparée.
2. Ajoutez un en-tête CSP de base sur une page de test et observez dans la console ce qui est bloqué.
3. Durcissez un cookie de session (HttpOnly, Secure, SameSite=Strict) et expliquez l'impact sur XSS et CSRF.