security-auditor

name

security-auditor

description

Audit de sécurité complet d'une application ou d'un code source — OWASP Top 10, analyse de dépendances, configuration serveur, cryptographie, secrets exposés. À utiliser quand l'utilisateur veut vérifier la sécurité de son projet. Se déclenche avec "audit sécurité", "security audit", "vérifier la sécurité", "est-ce que mon code est sécurisé", "analyse de sécurité". Also triggers on "audit my codebase", "find security flaws".

Security Auditor

1. Cadrage du périmètre

Avant toute analyse, établir :

Dimension	Questions clés
Type d'app	Web SPA, API REST/GraphQL, mobile, desktop, micro-services ?
Stack	Langages, frameworks, BDD, cloud provider
Surface d'attaque	Endpoints exposés, jobs batch, websockets, webhooks, S3 public ?
Assets critiques	PII, données bancaires, tokens, secrets, configs infra
Contexte réglementaire	PCI-DSS, RGPD, HIPAA, ISO 27001 ?

2. Authentification & Sessions

JWT — vérifications immédiates :

# Décoder un JWT sans vérifier la signature
echo "eyJ..." | cut -d. -f2 | base64 -d 2>/dev/null | jq .
# Vérifier alg: jamais "none", préférer RS256/ES256 à HS256 sur API publique

Checklist :

• alg != none ; signature vérifiée côté serveur
• exp présent et court (≤15 min pour access token)
• Refresh token stocké en HttpOnly cookie, pas en localStorage
• Révocation possible (blacklist Redis ou rotation de clé)
• MFA sur comptes privilégiés ; protection brute-force (rate-limit + lockout)

Cookies :

Set-Cookie: session=xxx; Secure; HttpOnly; SameSite=Strict; Path=/; Max-Age=3600

OAuth 2.0 / OIDC — pièges courants :

• Absence de state param → CSRF sur le callback
• redirect_uri trop permissive (*.example.com match evil.example.com)
• PKCE absent sur app mobile/SPA → authorization code interception

3. Contrôle d'accès & Autorisations

# MAUVAIS — contrôle côté client uniquement
if user.role == "admin":  # validé dans le JS du front
    show_admin_panel()

# BON — contrôle systématique côté serveur
@require_permission("admin:read")
def admin_view(request):
    ...

Vérifier :

• IDOR : GET /api/orders/1234 accessible par un autre utilisateur ?
• Mass assignment : PATCH /users/me accepte-t-il role ou is_admin ?
• Élévation horizontale et verticale de privilèges
• Endpoints admin non protégés par IP allowlist ou header interne

4. Validation des entrées & Injections

SQL Injection :

# VULNÉRABLE
query = f"SELECT * FROM users WHERE id = {user_id}"

# BON — paramétré
cursor.execute("SELECT * FROM users WHERE id = %s", (user_id,))

XSS :

// VULNÉRABLE
element.innerHTML = userInput;

// BON
element.textContent = userInput;
// + CSP header : Content-Security-Policy: default-src 'self'; script-src 'self'

Autres vecteurs à tester :

• Path traversal : ../../etc/passwd dans paramètres de fichier
• Command injection : os.system(f"convert {filename}") → filename = "x; rm -rf /"
• SSRF : URL fournie par l'utilisateur appelée côté serveur (AWS metadata endpoint)
• XXE : parsing XML sans désactiver les entités externes
• Open redirect : ?next=https://evil.com

5. Headers HTTP & Configuration TLS

Headers à vérifier (réponse serveur) :

curl -sI https://example.com | grep -iE "strict|content-security|x-frame|x-content|referrer|permissions"

Header	Valeur recommandée
Strict-Transport-Security	max-age=31536000; includeSubDomains; preload
Content-Security-Policy	policy stricte, pas de unsafe-inline
X-Frame-Options	DENY ou SAMEORIGIN
X-Content-Type-Options	nosniff
Referrer-Policy	strict-origin-when-cross-origin
Permissions-Policy	désactiver caméra/micro si non nécessaire

TLS :

# Tester avec ssllabs CLI ou nmap
nmap --script ssl-enum-ciphers -p 443 example.com
# Rejeter : TLS 1.0, TLS 1.1, SSLv3, RC4, DES, 3DES, NULL ciphers

CORS — configuration dangereuse :

// VULNÉRABLE
app.use(cors({ origin: '*', credentials: true }));
// credentials:true avec origin:* = erreur navigateur mais risque de mauvaise config
// Toujours whitelister les origines explicitement

6. Secrets & Configuration

# Scan de secrets dans le dépôt (à lancer en local ou CI)
trufflehog git file://. --only-verified
gitleaks detect --source . --verbose

# Vérifier l'historique git aussi
git log --all --full-history -- "**/*.env" "**/*secret*" "**/*key*"

Pièges fréquents :

• .env committé (vérifier .gitignore)
• Clés hardcodées dans le code : API_KEY = "sk-..."
• Credentials dans les logs applicatifs
• Secrets en clair dans les variables d'environnement exposées via /actuator/env (Spring) ou debug endpoints

7. Dépendances & Supply Chain

# Node.js
npm audit --audit-level=high
npx snyk test

# Python
pip-audit
safety check -r requirements.txt

# .NET
dotnet list package --vulnerable

# Java / Maven
mvn dependency-check:check

# Multi-langages
docker run --rm -v $(pwd):/app aquasec/trivy fs /app

Critères de décision :

• CVE CVSS ≥ 9.0 → bloquer le merge immédiatement
• CVE CVSS 7.0–8.9 → corriger dans le sprint courant
• Dépendance sans maintenance depuis >2 ans → planifier remplacement
• Vérifier les dépendances transitives, pas seulement directes

8. Cryptographie & Stockage

# MAUVAIS — MD5 ou SHA1 pour les mots de passe
import hashlib
hashed = hashlib.md5(password.encode()).hexdigest()

# BON — bcrypt ou argon2
from argon2 import PasswordHasher
ph = PasswordHasher(time_cost=3, memory_cost=65536)
hashed = ph.hash(password)

Vérifier :

• Chiffrement au repos pour PII et données sensibles (AES-256-GCM)
• TLS partout en transit (y compris BDD interne)
• Clés de chiffrement séparées des données (KMS, Vault)
• IV/nonce unique par opération de chiffrement
• Pas d'ECB mode pour le chiffrement symétrique

9. Logging & Monitoring

Ce qui ne doit PAS apparaître dans les logs :

# Anti-patterns
logger.info(f"User login: {username} / {password}")
logger.debug(f"JWT: {token}")
logger.error(f"DB error for query: {raw_sql_with_params}")

Checklist :

• Events de sécurité loggés : logins (succès/échec), changements de rôle, accès admin
• Logs sans PII (hash ou masquage des identifiants)
• Alerting sur tentatives brute-force, accès anormaux, erreurs 5xx en pic

10. Rapport de Findings

Classifier chaque finding :

Sévérité	Critère	Action
Critique	RCE, SQLi exploitable, credentials exposés	Hotfix immédiat, notifier CISO
Élevé	Auth bypass, IDOR sur données sensibles, XSS stocké	Corriger avant mise en prod
Moyen	CSRF, mauvais headers, secrets dans logs	Corriger dans le sprint
Faible	Headers manquants, verbose errors	Backlog priorisé
Informatif	Best practices, recommandations archi	Documentation

Structure d'un finding :

## [CRITIQUE] Injection SQL — endpoint /api/search

**Description** : Le paramètre `q` est interpolé directement dans la requête SQL.
**Preuve** : `GET /api/search?q=' OR '1'='1` → retourne tous les enregistrements.
**Impact** : Exfiltration complète de la base de données.
**Remédiation** :
  - Remplacer l'interpolation par des requêtes paramétrées (exemple ci-dessous)
  - Auditer tous les autres endpoints avec paramètres dynamiques
**Exemple corrigé** : [snippet de code]

Anti-patterns & Pièges

• Ne pas auditer uniquement le frontend : les vraies vulnérabilités sont côté serveur
• Éviter le security theater : headers sans CSP stricte, HTTPS avec TLS 1.0 encore actif
• Ne pas ignorer les dépendances transitives : la CVE est souvent dans un sous-package
• Pas de "sécurité par obscurité" : cacher l'URL admin n'est pas un contrôle d'accès
• Attention aux edge cases : les fichiers de backup (.bak, .old, ~) souvent oubliés dans le webroot
• JWT sans révocation : un token volé reste valide jusqu'à expiration
• Rate-limiting uniquement côté client : facilement contourné ; toujours côté serveur

Règles d'usage

• Adapter les recommandations au stack réel (Spring Security, Express middleware, ASP.NET filters…)
• Rester éthique : ne pas fournir d'exploit offensif sans contexte de pentest explicitement autorisé
• Prioriser par criticité métier (ex : données bancaires > logs analytics)
• Chaque remédiation = exemple de code dans le langage du projet
• Ne pas conclure sans avoir analysé le contexte réel de l'application