Audit de sécurité web en 48 heures : Laravel, Node.js et WordPress

Un audit utile n'est pas un théâtre d'outils au vert. Il s'agit de trouver ce qui peut faire tomber l'application ou filtrer des données, de le documenter avec des preuves, et de prioriser les corrections.

Cette méthodologie s'applique aux applications PHP/Laravel, Node.js et WordPress (multisite, Elementor, boutiques avec paiements). En présence d'ecommerce ou de passerelles locales, elle inclut checkout et webhooks — la même surface couverte par les paiements en ligne.

Répartition des 48 heures

Heures 0–4 : carte de surface

• Inventaire des routes publiques (web + API).
• Formulaires, uploads, webhooks de paiement, cron endpoints.
• Headers actuels, cookies, redirections.
• Sur WordPress : version, thème enfant, plugins actifs, utilisateurs administrator.
• En multisite : sites, super-admins et plugins réseau.

Heures 4–16 : authentification et session

• Reset de mot de passe, énumération d'utilisateurs, rate limiting.
• Cookies Secure / HttpOnly / SameSite.
• CSRF sur les formulaires qui changent l'état.
• JWT : exp, rotation, stockage non sécurisé dans localStorage.
• Admin WordPress ou Filament/Horizon exposé sans MFA.

Heures 16–32 : injection et logique métier

• SQL / ORM mal utilisé, XSS stocké, path traversal.
• Mass assignment dans Laravel ($fillable / $guarded).
• IDOR : peut-on voir la commande #id+1 ?
• Paiements : confirmer que le montant n'est pas fait confiance au client.
• Upload : type réel du fichier, pas seulement l'extension.

Heures 32–48 : dépendances et livrable

• composer / npm audit avec discernement.
• Plugins WordPress abandonnés ou avec advisories connus.
• Secrets dans le repo, .env exposé, backups publics.
• Rapport P0/P1/P2 + plan de remédiation par sprint.

Checklist pratique

1. Y a-t-il .env, .git ou des backups accessibles par URL ?
2. Login, reset et APIs sensibles ont-ils du rate limiting ?
3. Les cookies de session ont-ils les bons flags en HTTPS ?
4. Le CSRF est-il actif sur les formulaires qui changent l'état ?
5. Les policies/capabilities existent-elles et sont-elles appelées sur chaque route ?
6. Les uploads valident-ils le MIME réel ?
7. Les webhooks de paiement valident-ils signature/origine et sont-ils idempotents ?
8. Les headers de sécurité (CSP, HSTS) existent-ils sans casser le front ?
9. Les dépendances critiques ont-elles un responsable de mise à jour ?
10. Le déploiement peut-il réintroduire le même secret ou un vieux plugin ?

Laravel : points de revue

• Validation avec Form Requests sur toutes les entrées API.
• Autorisation : Policies/Gates sur show/update/destroy.
• Mass assignment : modèles avec $guarded = [] ou fillables dangereux.
• Fichiers : Storage sur disque privé ; URLs signées.
• Files d'attente avec backoff et dead-letter ; payloads sans PII inutile.
• APP_DEBUG=false en prod ; Telescope/Horizon non publics.

WordPress : points de revue

• Supprimer l'utilisateur admin générique ; revoir les rôles ; 2FA sur comptes privilégiés.
• XML-RPC : désactiver s'il n'y a pas d'app légitime qui en a besoin.
• REST : endpoints utilisateurs qui filtrent des infos.
• Uploads : blocage d'exécution dans uploads.
• WooCommerce : plugins de passerelle à jour ; webhooks avec permissions minimales.

Format du livrable

Chaque constat inclut : où, comment reproduire, risque, correctif suggéré et effort relatif. Lié à DevOps et Coolify et la cybersécurité .