Audit de sécurité web en 48 heures (Laravel, Node.js, WordPress)

Un audit utile n’est pas un PDF de 80 pages ni 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 prouver avec des preuves, et de décider quoi corriger en premier.

Cette méthodologie de 48 heures s’applique aux applications PHP/Laravel, Node.js et WordPress (multisite, Elementor, boutiques avec paiements). En présence d’e-commerce ou de passerelles locales, elle inclut checkout et webhooks — la même surface qui provoque souvent de vrais incidents.

Pourquoi c’est important (au-delà de la « conformité »)

Pensez à la sécurité comme au verrou d’un magasin : elle ne remplace pas le métier, mais sans elle n’importe qui peut entrer. Un constat tôt coûte un sprint ; un incident coûte des clients, de la réputation et des jours de pompiers.

• Argent : paiements manipulables ou webhooks sans signature.
• Données : commandes ou utilisateurs visibles via IDOR.
• Opérations : admin sans MFA, plugins abandonnés, .env public.
• Priorité : sans P0/P1/P2, tout semble urgent et rien n’est clôturé.

Concepts clés en langage clair

• Surface d’attaque : tout ce qu’un inconnu peut toucher (formulaires, APIs, uploads, admin).
• Authentification vs autorisation : « qui vous êtes » vs « ce que vous pouvez faire ». Des échecs différents.
• IDOR : passer de /orders/100 à /orders/101 et voir la commande d’autrui.
• Injection : fournir des données que le système traite comme des instructions (SQL, XSS, path traversal).
• Dépendances : code tiers avec bugs connus ; mettre à jour, c’est aussi de la sécurité.

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 confié au client.
• Upload : type réel du fichier, pas seulement l’extension.

Heures 32–48 : dépendances et livrable

• composer / npm audit avec discernement (bruit vs risque réel).
• 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.

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.

Erreurs fréquentes en « audit »

• Se fier uniquement à un scanner automatique sans valider les constats à la main.
• Ignorer la logique métier (montants, IDs de commande, permissions par rôle).
• Livrer une liste de CVE sans prioriser l’impact sur ce produit.
• Ne pas revoir le déploiement : le même secret ou vieux plugin revient au release suivant.
• Tout marquer critique : l’équipe sature et ne corrige pas ce qui est exploitable aujourd’hui.

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 ?

Format du livrable

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