Vous disposez d’un pare-feu. Vous utilisez HTTPS. Vous exécutez npm audit. Mais si je peux modifier la charge utile JSON d’une requête « Acheter » pour envoyer « prix : 0,01 » et que votre serveur l’accepte, votre pare-feu est inutile.

Les tests d’intrusion (Pentesting) sont la discipline de l’ingénierie contradictoire. Il ne s’agit pas de « cocher des cases » pour assurer la conformité. Il s’agit d’essayer activement de détruire votre propre application avant que quelqu’un d’autre ne le fasse.

Chez Maison Code Paris, nous considérons la sécurité comme la forme ultime d’assurance qualité. Un bug qui fait planter l’application est ennuyeux. Un bug qui fait fuir 10 000 cartes de crédit clients est existentiel.

Pourquoi Maison Code en parle

Chez Maison Code Paris, nous agissons comme la conscience architecturale de nos clients. Nous héritons souvent de stacks “modernes” construites sans compréhension fondamentale de l’échelle.

Nous abordons ce sujet car il représente un point de pivot critique dans la maturité de l’ingénierie. Une mise en œuvre correcte différencie un MVP fragile d’une plateforme résiliente de niveau entreprise.

Les limites de l’automatisation

La plupart des équipes utilisent un scanner automatisé (comme OWASP ZAP ou Nessus) et pensent qu’ils sont sécurisés. Les scanners sont excellents pour détecter les erreurs de syntaxe :

Injection SQL (' OU 1=1).
XSS (<script>alerte(1)</script>).
Bibliothèques obsolètes (CVE-2023-XXXX).

Les scanners ne parviennent pas à détecter les erreurs logiques :

“Puis-je appliquer le même code de réduction 50 fois simultanément ?”
« Puis-je consulter l’historique des commandes de l’ID utilisateur 5 si je suis connecté sous l’ID utilisateur 4 ? »
« Puis-je définir le prix de l’article sur négatif ? »

Il s’agit de vulnérabilités de logique métier, qui représentent la majorité des pertes financières dans le commerce électronique moderne.

Vulnérabilité 1 : IDOR (Insecure Direct Object Reference)

Il s’agit de la faille la plus courante dans les API modernes (GraphQL/REST). Cela se produit lorsque vous faites confiance au client pour vous dire à quelle ressource accéder, sans vérifier la propriété.

L’attaque : L’utilisateur A se connecte. Il regarde l’URL ou l’onglet Réseau : GET /api/orders/5001 Ils le changent en : GET /api/orders/5002

Si le serveur renvoie la commande de l’utilisateur B, vous disposez d’un IDOR.

Le code vulnérable :

// MAUVAIS : faire confiance à l'ID fourni par l'utilisateur
app.get('/api/orders/:id', async (req, res) => {
  const order = attendre db.order.findUnique({
    où : { identifiant : req.params.id }
  });
  res.json(commande);
});

Le code sécurisé :

// BON : étendre la requête à l'utilisateur authentifié
app.get('/api/orders/:id', async (req, res) => {
  const session = attendre getSession(req);
  const order = attendre db.order.findFirst ({
    où : { 
      identifiant : req.params.id,
      userId : session.userId // La vérification critique
    }
  });
  
  if (!order) return res.status(404).send("Not Found"); // Ne dites pas "Interdit", dites simplement "Introuvable" pour éviter les fuites
  res.json(commande);
});

Vulnérabilité 2 : Conditions de concurrence (The Coupon Hack)

Les serveurs Web sont simultanés. Ils traitent des milliers de requêtes par seconde. Si la logique de votre base de données n’est pas “Thread Safe” (ou Transaction Safe), vous êtes vulnérable.

L’attaque :

Le site envoie un Code Promo : « SAVE50 » (Limite de 1 utilisation par client).
L’attaquant écrit un script pour envoyer 50 requêtes HTTP POST à /apply-coupon simultanément (dans un délai de 5 ms).
Le serveur traite la demande 1 : « L’utilisateur a utilisé le coupon ? Non. Appliquer la remise. »
Le serveur traite la demande 2 (avant que la demande 1 ne soit validée dans la base de données) : « L’utilisateur a utilisé le coupon ? Non. Appliquer la remise. »
Résultat : l’utilisateur bénéficie d’une réduction de 50x. La commande est gratuite.

Le correctif : verrouillage de la base de données : Vous devez utiliser Transactions avec le niveau d’isolement correct ou le verrouillage de ligne explicite.

-- PostgreSQL/MySQL
COMMENCER ;
SELECT * FROM utilisateurs WHERE id = 1 FOR UPDATE ; -- Verrouille la ligne
- Vérifier l'utilisation des coupons
- Appliquer le coupon
MISE À JOUR des utilisateurs SET coupon_used = true WHERE id = 1 ;
COMMETTRE;

En termes Prisma/ORM, utilisez €transaction avec une isolation interactive si possible, ou utilisez un Mutex dans Redis s’il s’agit de compteurs distribués.

Vulnérabilité 3 : Attaques de la chaîne d’approvisionnement

En 2025, vous écrivez 10 % de votre code. Les 90 % restants proviennent de node_modules. Les pirates ont cessé d’attaquer votre serveur ; ils attaquent vos dépendances. Ils publient un paquet comme « lodash-utils » (typosquatting) ou compromettent le compte d’un responsable de paquet populaire.

Défense en profondeur :

Lockfiles : validez toujours package-lock.json. Il garantit des versions exactes.
Audits CI : exécutez npm audit --audit-level=high dans votre pipeline de build. Échec de la construction si des critiques sont trouvés.
Outils modernes : utilisez Socket.dev ou Snyk. Ils analysent le comportement du package (« Pourquoi cette bibliothèque CSS a-t-elle besoin d’un accès réseau ? »).

Vulnérabilité 4 : injection NoSQL

Tout le monde connaît l’injection SQL. Mais si vous utilisez MongoDB, vous n’êtes pas à l’abri. MongoDB autorise les objets de requête. Si vous acceptez le JSON brut du client : db.users.find({ username: req.body.username }).

L’attaque : L’utilisateur envoie JSON : { "username": { "€gt": "" } }. Cela se traduit par : “Rechercher les utilisateurs dont le nom d’utilisateur est supérieur à une chaîne vide.” Cela correspond à tout le monde. L’attaquant se connecte en tant que premier utilisateur administrateur.

Le correctif : Désinfectez les entrées. Ne transmettez jamais req.body directement à une requête de base de données. Utilisez des bibliothèques comme « zod » pour valider la structure (assurez-vous que « nom d’utilisateur » est une chaîne, pas un objet).

importer { z } depuis 'zod' ;

const LoginSchema = z.object({
  nom d'utilisateur : z.string(), // Rejette les objets comme { $gt: "" }
  mot de passe : z.string()
});

const corps = LoginSchema.parse(req.body); // Lance si invalide

L’exercice de l’équipe rouge

Chez Maison Code, nous vous recommandons un exercice Red Team trimestriel. Nous désignons 2 ingénieurs qui sont autorisés à attaquer l’environnement de Staging.

Ils essaient de contourner le paiement.
Ils essaient d’élever les privilèges.
Ils essaient d’accéder aux données des autres utilisateurs.

Cette « gamification » de la sécurité crée une culture dans laquelle les développeurs sont fiers de trouver des failles, plutôt que honteux.

10. Programmes de Bug Bounty (les pirates informatiques en tant qu’employés)

Vous ne pouvez pas embaucher suffisamment d’ingénieurs en sécurité. Mais vous pouvez embaucher les hackers du monde entier. Nous aidons les clients à se lancer sur HackerOne ou Bugcrowd.

Politique : “Si vous trouvez un P1 (Critique), nous payons 5 000 €.”
Résultat : Dans les 24 heures, 500 chercheurs sonderont votre site. Ils trouveront les choses que votre scanner à 100 000 € a manquées. “J’ai trouvé un moyen de contourner 2FA en supprimant le paramètre token.” Payer 5 000 € pour cette découverte revient moins cher qu’une amende de 5 millions de dollars en vertu du RGPD.

11. Ingénierie sociale (le pare-feu humain)

Votre pare-feu est puissant. Votre réceptionniste est sympa. Les pirates le savent. Phishing Simulation : Nous envoyons de faux e-mails à vos employés. “Urgent : le PDG a besoin d’un virement bancaire.” S’ils cliquent, ils sont inscrits à une formation. Sécurité physique : Puis-je entrer efficacement dans votre bureau ? La sécurité n’est pas qu’un code ; ce sont les gens.

12. Gestion de la posture de sécurité du cloud (CSPM)

Vous avez sécurisé le code. Mais avez-vous laissé le compartiment S3 ouvert ? Les outils CSPM (Wiz, Orca) analysent votre environnement AWS. “Alerte : le port 5432 de la base de données RDS est ouvert à 0.0.0.0/0”. Ce n’est pas un bug de code. C’est un bug de configuration. Nous traitons l’Infrastructure as Code (Terraform) comme une frontière de sécurité. checkov s’exécute dans notre pipeline CI pour bloquer tout commit qui ouvre un groupe de sécurité au monde.

13. Analyse secrète (le problème de l’historique Git)

Vous avez accidentellement commis AWS_SECRET_KEY en 2021. Vous l’avez supprimé lors du prochain commit. C’est toujours dans l’historique .git. Les pirates clonent votre dépôt et consultent le journal. Nous utilisons TruffleHog ou GitGuardian pour analyser l’intégralité de l’historique des validations. Si un secret est découvert, nous le faisons pivoter immédiatement. La révocation de la clé est le seul correctif.

14. Conclusion

La sécurité n’est pas un produit que vous achetez. C’est un état d’esprit. Si vous pensez « Je suis trop petit pour être piraté », vous vous trompez. Les robots analysent constamment chaque adresse IP sur Internet. Ils ne se soucient pas de savoir si vous êtes un Fortune 500 ou un blog ; si vous avez une vulnérabilité, ils l’exploiteront pour exploiter des cryptomonnaies ou envoyer du spam.

Traitez votre candidature comme une forteresse. Vérifiez chaque porte. Ne faites confiance à personne.

**[Engagez nos Architectes](/contact)**.