Module 5 — Sécu applicative & RGPD

🎯 OWASP Top 10 — l'essentiel

L'OWASP Top 10 est la liste de référence des risques applicatifs web les plus critiques. Mise à jour tous les 3-4 ans.

Les 5 à connaître par cœur (côté dev)

A01 — Broken Access Control

Un user peut accéder à des données/actions qu'il ne devrait pas. Ex: /admin/users/42 accessible sans rôle admin, ou /api/orders/123 renvoie la commande même si elle appartient à un autre user.

Mitigation : middleware d'auth/authz systématique côté serveur — JAMAIS faire confiance à l'absence du bouton côté front. Vérifier que l'user a le droit pour CHAQUE endpoint.

A02 — Cryptographic Failures

Données sensibles transmises ou stockées sans chiffrement / avec algos faibles. Ex: passwords stockés en clair, MD5, SHA1.

Mitigation : HTTPS obligatoire partout (cf module 2), hashing avec bcrypt/argon2 pour passwords (jamais MD5/SHA1), chiffrement at-rest sur données sensibles (BDD, backups).

A03 — Injection (SQL, NoSQL, OS command)

Entrée utilisateur non sanitisée injectée dans une requête. Ex classique :

# VULNÉRABLE
query = f"SELECT * FROM users WHERE email = '{user_input}'"
# Si user_input = "x' OR '1'='1" → retourne tous les users

# SAFE — requête paramétrée
query = "SELECT * FROM users WHERE email = %s"
cursor.execute(query, (user_input,))

Mitigation : TOUJOURS utiliser des requêtes paramétrées / un ORM. JAMAIS de concaténation de string en SQL. Pareil pour shell commands : utiliser subprocess.run([...], shell=False), pas os.system(f"...").

A05 — Security Misconfiguration

Configs par défaut, comptes admin/admin, ports inutiles ouverts, messages d'erreur verbeux qui exposent la stack. Le piège le plus fréquent.

Mitigation : hardening checklist (cf modules 1-2), secure defaults, masquer les versions, désactiver les modes debug en prod.

A07 — Identification & Authentication Failures

Pas de 2FA, sessions trop longues, password policies faibles, brute-force permis.

Mitigation : 2FA obligatoire (cf module 3), rate-limiting sur /login (cf module 2), sessions courtes (4-8h max, regeneration après priv escalation), bcrypt avec coût élevé.

⚔️ XSS — Cross-Site Scripting en détail

Le XSS permet à un attaquant d'injecter du JavaScript dans une page que d'autres users vont voir → vol de cookies, défacement, redirection malveillante.

3 types de XSS

• Stored XSS : payload sauvegardé en BDD (commentaire, message), exécuté pour tout viewer ultérieur. Le plus dangereux.
• Reflected XSS : payload dans URL/POST, renvoyé directement dans la page. Nécessite que la victime clique un lien malveillant.
• DOM-based XSS : injection via manipulation JS côté client de location.hash, document.write, etc.

Mitigation

# Côté serveur (Python Jinja2 / Django auto-escape activé par défaut)
{{ user_input }}      # auto-escapé : < devient &lt;
{{ user_input|safe }} # DANGEREUX, à éviter sauf certitude absolue

# Côté JS — utiliser textContent au lieu de innerHTML
element.textContent = userInput;  // safe
element.innerHTML = userInput;     // DANGEREUX

# Headers nginx (cf module 2)
add_header Content-Security-Policy "default-src 'self'; script-src 'self'" always;

🔧 Hardening WordPress

WordPress reste l'application web la plus piratée au monde (taille de l'install base + plugins fragiles). Checklist de durcissement.

Niveau 1 — l'évident

• Garder WP core + thème + plugins à jour (MAJ auto si possible)
• Supprimer les plugins/thèmes inutilisés (pas juste désactivés)
• 2FA sur tous les comptes admin (plugin Wordfence ou Two Factor)
• Rate-limit /wp-login.php au niveau nginx (cf module 2)
• Désactiver l'éditeur de code dans le dashboard : define('DISALLOW_FILE_EDIT', true);

Niveau 2 — moins connus mais critiques

• Désactiver XML-RPC : add_filter('xmlrpc_enabled', '__return_false'); (souvent utilisé pour brute-force)
• Purger les Application Passwords et désactiver via mu-plugin :

  // mu-plugins/disable-app-passwords.php
  <?php
  add_filter('wp_is_application_passwords_available', '__return_false');

• Désactiver wp-cron (utiliser un vrai cron Linux à la place) :

  // wp-config.php
  define('DISABLE_WP_CRON', true);
  // crontab : */15 * * * * curl -s https://votre-site.com/wp-cron.php?doing_wp_cron

• Restreindre wp-admin par IP via nginx (basic auth ou whitelist IP)
• Bloquer accès direct aux fichiers PHP de uploads :

  location ~* /wp-content/uploads/.*\.php$ {
      deny all;
  }

Niveau 3 — pour les sites critiques

• WAF (CloudFlare WAF, Wordfence Premium)
• Monitoring intégrité fichiers (modifications détectées, alerte)
• Logs centralisés cf module 4

🇪🇺 RGPD — l'essentiel opérationnel

Le RGPD (Règlement Général sur la Protection des Données) impose des obligations à toute entité qui traite des données personnelles d'européens. La CNIL est l'autorité de contrôle en France.

6 principes fondamentaux

Principe	Concrètement
Licéité, loyauté, transparence	Base légale claire (consentement / contrat / intérêt légitime…) + information de la personne
Limitation des finalités	Données collectées pour un usage précis, pas réutilisables pour autre chose
Minimisation	Ne collecter QUE le strict nécessaire — pas "tout au cas où"
Exactitude	Données à jour, possibilité de correction
Limitation de conservation	Durée fixée selon finalité — purge automatique après
Intégrité & confidentialité	Sécurité technique adéquate (chiffrement, contrôle accès)

Droits des personnes

1. Droit d'accès : obtenir copie de leurs données (sous 1 mois)
2. Droit de rectification : corriger une donnée inexacte
3. Droit à l'effacement ("droit à l'oubli") : suppression sur demande, sauf exceptions légales
4. Droit à la portabilité : récupérer ses données en format machine-readable
5. Droit d'opposition : refuser un traitement (marketing surtout)
6. Droit à la limitation : geler le traitement en cas de contestation

Vous devez avoir un process documenté pour traiter ces demandes — pas juste "on verra le jour J".

📝 Documents RGPD à avoir

1. Registre des traitements

Obligatoire pour toute org dès qu'elle traite des données perso (sauf moins de 250 employés ET pas de traitement à risque ET pas régulier — exception rare en pratique).

Pour chaque traitement, documenter :

• Finalité (pourquoi)
• Catégories de données (quoi : nom, email, IP, géoloc, santé…)
• Catégories de personnes (clients, prospects, employés…)
• Destinataires (qui voit la donnée : équipe interne, sous-traitants)
• Durée de conservation
• Mesures de sécurité (chiffrement, contrôle accès, 2FA…)
• Transferts internationaux (USA, Inde…) avec base légale

Template Excel CNIL : cnil.fr/RGPD-registre

2. DPA (Data Processing Agreement)

Contrat de sous-traitance avec chaque tiers à qui vous confiez des données perso (Zoho, Mailjet, AWS, Stripe, n8n cloud, votre webmaster freelance…). Article 28 RGPD obligatoire.

Le DPA doit fixer : objet, durée, nature/finalité du traitement, type de données, obligations du sous-traitant, sous-traitance ultérieure, fin du contrat.

La plupart des grands SaaS ont un DPA standard à signer en ligne (Zoho, AWS, Stripe, Mailjet, etc.).

3. Politique de confidentialité publique

Sur votre site web : quelles données vous collectez, pourquoi, durée, droits des personnes, contact DPO/responsable. Modèle CNIL : cnil.fr/modeles

4. Charte interne & PSSI

Politique de Sécurité des Systèmes d'Information à diffuser aux employés. Pas obligatoire mais fortement recommandée.

⏰ Notification de violation — 72h

L'article 33 RGPD impose de notifier la CNIL dans les 72 heures suivant la prise de connaissance d'une violation de données personnelles (sauf si risque négligeable).

Qu'est-ce qu'une "violation" ?

• Confidentialité : accès non autorisé (piratage, divulgation)
• Intégrité : modification non autorisée
• Disponibilité : perte d'accès (ransomware, destruction backup)

Procédure

1. Évaluer le risque pour les personnes (volume, sensibilité, conséquences)
2. Si risque significatif → déclaration en ligne sur notifications.cnil.fr
3. Documenter même si risque négligeable (registre des violations interne)
4. Si risque ÉLEVÉ → informer aussi les personnes concernées directement (article 34)

Contenu de la notification CNIL

• Nature de la violation (catégorie + nombre approximatif de personnes/enregistrements)
• Coordonnées du DPO / contact
• Conséquences probables
• Mesures prises ou envisagées (contention, remédiation)

🌍 Transferts internationaux

Envoyer des données perso vers un pays hors UE/EEE est encadré. Les fournisseurs US (AWS US, Google US, OpenAI…) sont particulièrement scrutés depuis l'arrêt Schrems II.

Solutions par ordre de préférence

1. Pas de transfert — choisir la région EU du fournisseur (Zoho EU, AWS Frankfurt, OVH France…)
2. Décision d'adéquation CE (pays jugé "équivalent") — actuellement : Andorre, Argentine, Canada (partiel), UK, Suisse, Japon, Corée, Israël, Nouvelle-Zélande
3. SCC (Standard Contractual Clauses) + Transfer Impact Assessment — pour les USA notamment
4. BCR (Binding Corporate Rules) — règles internes contraignantes (gros groupes)
5. Consentement explicite — fragile, à éviter pour du transfert systématique

Cas pratique Ezway

Vous utilisez OpenAI API (US) dans un workflow n8n qui traite des leads clients. Compliance check :

• OpenAI est aux USA → transfert hors UE
• OpenAI propose des SCC dans son DPA
• Mais OpenAI peut être contraint par lois US (FISA 702) → risque résiduel
• Mitigation : anonymiser les données avant envoi (pas de nom/email, juste contenu textuel), désactiver training sur vos données via API param
• Documenter dans votre registre des traitements

Alternative : utiliser Anthropic via AWS Bedrock région Frankfurt, ou Mistral (FR), ou Claude Enterprise (DPA EU disponible).

🎯 Cas particuliers à connaître

Données de santé / mutuelles

Catégorie ULTRA-sensible (article 9 RGPD). Hébergement obligatoire chez un HDS (Hébergeur de Données de Santé) certifié. Liste : esante.gouv.fr.

Conséquence cas vécu (cf mémoire) : impossible de fournir un service SAV à un client mutuelle santé via votre stack standard. Il faudrait certifier le VPS/n8n HDS, ou refuser ce vertical, ou sous-traiter à un partenaire HDS.

Cookies & tracking

Bandeau cookies obligatoire si vous utilisez des cookies non essentiels (analytics, marketing). Doit permettre le REFUS aussi facile que l'acceptation (pas de dark pattern).

Outils conformes : Iubenda, Axeptio (FR), Klaro (OSS).

Vidéosurveillance / badges

Si vous avez de la vidéosurveillance ou des badges d'accès dans vos locaux : déclaration CNIL spécifique + information des employés/visiteurs + durée de conservation max 1 mois (sauf incident).