Pourquoi je passe mes soirs sur TryHackMe (et pourquoi tout dev senior devrait s'y mettre)
Ce que l'apprentissage de la sécurité offensive sur TryHackMe change concrètement dans la façon dont je conçois et code une API en production.
Coder une API et savoir la casser, ce n'est pas le même métier — mais ça devrait être la même personne
Je ne suis pas pentester. Je le dis clairement parce que je vois trop de devs qui, après quelques rooms TryHackMe, se mettent à vendre de l'audit sécurité comme s'ils avaient une décennie d'expérience offensive. Je fais l'inverse : j'apprends sérieusement, sur mon temps, sans en faire une offre commerciale tant que je n'ai pas le niveau pour l'assumer.
Pourquoi je fais ça sur mon temps plutôt que de sous-traiter la question
En tant qu'architecte qui livre en prod, je décide des mêmes points qu'un attaquant regarde en premier : la surface d'authentification, les headers exposés, la validation d'entrée, les permissions par défaut. Comprendre comment on énumère un endpoint, comment on exploite une IDOR ou un JWT mal vérifié, ça change directement la façon dont je code une API — pas après coup en audit, mais au moment où j'écris le guard.
# le genre d'énumération basique qu'on répète jusqu'à l'automatisme
nmap -sV -p- target.thm
ffuf -u https://target.thm/FUZZ -w wordlist.txt
Ce n'est pas glamour. La majorité du temps sur TryHackMe, c'est de la lecture de doc, des échecs répétés sur une privilege escalation qui ne veut pas passer, et la relecture du même writeup plusieurs fois avant de comprendre l'étape qui manquait. C'est exactement le même apprentissage que celui d'un dev sur n'importe quelle techno — sauf que le feedback est immédiat et sans complaisance : soit ça exploite, soit ça n'exploite pas.
Ce que ça change concrètement dans mon code
Depuis que j'ai pris cette pratique au sérieux, je relis mes propres endpoints différemment. Je ne me demande plus seulement "est-ce que ça marche pour le cas nominal", je me demande "qu'est-ce que je testerais en premier si je voulais casser ça". Rate limiting, validation stricte des types d'entrée, headers de sécurité par défaut (CSP, HSTS), séparation claire entre ce qu'un token peut et ne peut pas faire — ce sont des réflexes qui viennent de l'autre côté du miroir, pas d'une checklist lue une fois.
Pourquoi je pense que tout dev senior devrait s'y mettre
Un dev qui n'a jamais essayé de casser une API construit des défenses en pensant à ce qu'un utilisateur normal ferait. Un dev qui a passé des soirs à essayer d'exploiter des applications volontairement vulnérables construit des défenses en pensant à ce qu'un utilisateur malveillant ferait en premier. Ce n'est pas la même API à l'arrivée, même si le cahier des charges fonctionnel est identique.
Je ne vends pas encore d'audit sécurité offensif — je ne suis pas assez loin dans la préparation pour l'assumer sérieusement face à un client. Mais une bonne partie de ce que j'apprends sur TryHackMe sert déjà, aujourd'hui, dans le code que je livre en prod. Le jour où le reste sera prêt, ce sera un service. En attendant, c'est juste la bonne façon de coder une API qu'on ne veut pas voir citée dans un rapport d'incident.