📖 Manuel

OWASP Checker

Workflow

Étape 1 — Cadrage initial

Avant d'auditer, demande (ou infère du contexte) :

• Stack : langage, framework, ORM, moteur de template
• Type : web MPA, SPA+API, API REST/GraphQL, microservices, mobile backend
• Scope : toute l'app ou un composant précis (auth, paiement, upload…)
• Profondeur : revue de code statique / checklist / test dynamique (pentest)

Adapte les catégories à auditer : une API sans UI n'a pas de XSS stocké, un monolithe sans Docker n'a pas de misconfiguration container.

Étape 2 — A01 Broken Access Control (criticité : critique)

Vérifications clés :

• Chaque endpoint applique l'autorisation côté serveur (jamais côté client)
• Pas d'IDOR : les IDs en URL/paramètres sont vérifiés contre l'utilisateur courant
• Pas de force browsing : les routes protégées retournent 401/403, pas 200
• Séparation des rôles testée (admin, user, guest)

Exemple de faille IDOR — Node.js Express :

// ❌ Vulnérable
app.get('/orders/:id', auth, (req, res) => {
  db.query('SELECT * FROM orders WHERE id = ?', [req.params.id]);
});

// ✅ Corrigé
app.get('/orders/:id', auth, (req, res) => {
  db.query('SELECT * FROM orders WHERE id = ? AND user_id = ?',
    [req.params.id, req.user.id]);
});

Commande de test rapide :

# Tester l'accès cross-user avec curl
curl -H "Authorization: Bearer <token_user_A>" https://api.example.com/orders/42
# 42 appartient à user B → doit retourner 403, pas les données

Étape 3 — A02 Cryptographic Failures (criticité : critique)

Checklist :

• [ ] TLS 1.2+ obligatoire, TLS 1.0/1.1 désactivés (testssl.sh ou SSLLabs)
• [ ] Passwords : bcrypt (cost ≥ 12) ou Argon2id — jamais MD5/SHA1/SHA256 plain
• [ ] Secrets absents du code source (scan avec trufflehog ou gitleaks)
• [ ] Données sensibles absentes des logs, URLs, et réponses d'erreur

Scan de secrets dans git :

# Installer gitleaks et scanner le repo complet
docker run -v $(pwd):/path zricethezav/gitleaks:latest detect --source /path --verbose

Hashing correct en Node.js :

import bcrypt from 'bcrypt';
// ✅ cost factor 12, résistant aux GPU
const hash = await bcrypt.hash(password, 12);
const ok   = await bcrypt.compare(input, hash);

Étape 4 — A03 Injection (criticité : critique)

Vecteurs à couvrir :

• SQL (raw queries, ORM mal utilisés, stored procedures)
• NoSQL (MongoDB $where, opérateurs injectés dans le body JSON)
• OS Command (exec, shell_exec, subprocess)
• SSTI (templates Jinja2/Twig avec input utilisateur non échappé)
• XSS stocké/réfléchi/DOM

SQL injection — Python SQLAlchemy :

# ❌ Injection directe
query = f"SELECT * FROM users WHERE email = '{email}'"

# ✅ Paramétré
result = db.execute(text("SELECT * FROM users WHERE email = :e"), {"e": email})

Test NoSQL injection (MongoDB) :

# Tester un login — envoyer un objet au lieu d'une string
curl -X POST https://api.example.com/login \
  -H "Content-Type: application/json" \
  -d '{"username": {"$gt": ""}, "password": {"$gt": ""}}'
# Si 200 → injection confirmée

Étape 5 — A04 Insecure Design (criticité : haute)

Points de contrôle :

• Threat modeling réalisé sur les flux critiques (paiement, reset password, upload)
• Rate limiting présent sur login, SMS/email OTP, reset password
• Anti-automation (CAPTCHA, device fingerprint) sur les formulaires publics
• Failles logiques métier : contournement de prix, abus de promotions, skip d'étapes workflow

Rate limiting — Express (exemple) :

import rateLimit from 'express-rate-limit';
app.use('/auth/login', rateLimit({
  windowMs: 15 * 60 * 1000, // 15 min
  max: 10,
  message: { error: 'Trop de tentatives, réessayez plus tard.' }
}));

Étape 6 — A05 à A10 (synthèse actionnable)

Headers de sécurité — configuration Nginx minimale :

add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "DENY" always;
add_header Content-Security-Policy "default-src 'self'" always;
add_header Permissions-Policy "geolocation=(), microphone=()" always;

Audit dépendances NPM/Python :

npm audit --audit-level=high
pip-audit --requirement requirements.txt
trivy fs . --severity HIGH,CRITICAL

Étape 7 — Matrice de conformité

Produis un tableau récapitulatif :

Score global : X/10 catégories conformes. Catégories bloquantes (critiques non conformes) à traiter avant mise en production.

Étape 8 — Plan de remédiation priorisé

Classe les actions selon la matrice Impact × Effort :

1. Immédiat (< 1 semaine) : failles critiques exploitables (injection, IDOR, secrets exposés)
2. Court terme (1–4 semaines) : misconfiguration, composants vulnérables, headers manquants
3. Long terme (1–3 mois) : refonte design (rate limiting, threat modeling, logging structuré)

Pour chaque item : fournir l'extrait de code avant/après + la référence OWASP officielle (ex : A03:2021).

Garde-fous et anti-patterns

• Ne jamais fournir d'exploit fonctionnel sans mandat de pentest explicite — donner des PoC conceptuels uniquement
• Ne pas cocher "conforme" par défaut si l'information est insuffisante — signaler le manque d'info
• ORM ≠ immunité SQL : Hibernate, Prisma, SQLAlchemy peuvent être contournés avec raw() ou text() mal utilisés
• HTTPS ≠ chiffrement complet : valider aussi le chiffrement au repos et dans les logs
• Dépendances transitives : npm audit ne couvre pas toujours les sous-dépendances — utiliser trivy ou snyk
• A04 Insecure Design ne se corrige pas avec du code : nécessite une revue d'architecture

Bonnes pratiques 2026

• Utiliser OWASP ASVS (Application Security Verification Standard) pour un audit structuré par niveau (L1/L2/L3)
• Intégrer SAST (Semgrep, Sonarqube) et SCA (Trivy, Snyk) dans la CI pour détecter les régressions
• Adopter OpenID Connect / OAuth 2.1 pour l'authentification plutôt que les sessions custom
• Préférer Passkeys (WebAuthn) au mot de passe pour éliminer structurellement A07
• Pour les APIs, appliquer les vérifications OWASP API Security Top 10 2023 en complément