le retour froid et brutal
J’étais tranquillement en train de verifier mon site actuel, tu sais, le truc carré avec CSP, MFA, certificats et compagnie, quand j’ai eu une idée farfelue: « tiens, si j’allais voir ce que devient mon tout premier site ? » Oui, l’équivalent numérique de rouvrir ton Skyblog.
Résultat : OMG !, retour en 2000. Même mois d’octobre. Même énergie de gars persuadé d’être un génie du web. Et la bête est toujours là, merci Wayback Machine !!!! figée dans sa gloire passée : un joli frameset avec bannière en haut, menu à gauche, contenu au centre. Le temple du bon goût, codé avec FrontPage 98 et Dreamweaver 3. Rien que ça.
À l’époque, je pensais que mettre des frames, c’était pro. Maintenant je sais que c’est juste un cauchemar pour les webmasters et la porte ouverte au clickjacking. Mais bon, j’avais 56 ko de courage et un firewall mental et je pensais que aller sur mirc pour aprendre faisais de moi un tenor.
La bannière ? Un chef-d’œuvre visuel : GIFs, fond fixe, marquee jaune, et le fameux « On décline toute responsabilité » qui défile comme un avertissement cosmique. On sent le mec sûr de lui : “je t’explique comment hacker ton PC, mais si tu le plantes, c’est ton problème.”
Le menu latéral, lui, c’est un musée : *Virus NEWS*, *Java-scripts*, *Trucs & Astuces*, *Mails gratos*… bref, le buffet à volonté des failles potentielles. Tout ce qui brille, je le colle.
Et la zone principale ? Là, c’est Disneyland. Applets Java, scripts pompés sur javascript.internet.com, blink, bgsound, tout ce que le HTML 4 pouvait offrir de pire. Et au milieu de ce chaos : un formulaire magique « Besoin d’un crack ou d’un numéro de série ? ». Oui. Sur ma page d’accueil. J’assume. C’était ma contribution personnelle à l’internet libre et totalement irresponsable.
Le pire, c’est que j’étais fier. Les meta-tags “Generator : FrontPage 4.0” s’affichaient comme un badge d’honneur. Et j’avais même un compteur de visites, évidemment, parce que rien ne dit “site pro” comme “vous êtes le visiteur n° 42 depuis 2000”.
Et que dire de mes scripts maison ? Un bloqueur de clic-droit pour empêcher la copie du code. Oui, j’avais inventé la DRM pour du HTML… sans imaginer une seconde que Print Screen existait. Niveau sécurité, c’était l’âge de pierre, mais j’y croyais dur comme fer.
Et alors mes pages “astuces Windows 9x”… une pure dinguerie. J’expliquais comment “supprimer SETVER.EXE pour gagner de la mémoire”, “tweaker le registre pour aller plus vite”, ou “forcer Windows à utiliser les pilotes optimisés”.
En clair : une check-list pour flinguer ton système d’exploitation en trois lignes de .bat.
En relisant ça, je me rends compte que ma philosophie de l’époque était simple :
> “Si ça marche pas, c’est normal. Et si ça marche du premier coup, on casse pour comprendre pourquoi.”
Et franchement, ça résume bien ma méthode d’apprentissage.
Parce que soyons clairs : ce site, c’était un festival de mauvaises idées, mais chaque plantage m’a appris un truc. J’ai appris à casser, observer, corriger, recommencer. À force d’erreurs, j’ai compris que la sécurité, c’est pas une checklist à réciter, c’est une façon de penser : comprendre ce que le système n’a **pas prévu**.
Alors oui, c’était moche, c’était vulnérable, et ça puait la bidouille. Mais sans ce foutoir de frames, de cracks et de clignotants, je n’aurais probablement jamais développé cette obsession pour la rigueur, le durcissement et la supervision.
Mon vieux site, c’est mon musée des horreurs perso : le jour où j’ai compris que la curiosité sans cadre, ça finit toujours en -debug.
Fondamentaux à ne jamais négocier
Je vais pas te faire tout le catalogue des trucs que j’ai mis en place tu t’en doutes, j’ai des couches et des couches. Mais il y a un minimum que tout le monde doit connaître avant de crier “c’est sécurisé” en se versant un café. Et si tu mets un WordPress, sache que deux choses sont vraies : 1) des robots vont scanner wp-login dans les cinq minutes, 2) un username “admin” et un mot de passe “password123” ne protègent que ta fierté. Donc voilà les fondamentaux, version pas chiante.
Chaque plugin, thème ou extension, c’est un putain de port d’entrée. Tu veux réduire la surface d’attaque ? Commence par réduire ton confort.
• Supprime tout module inutile. Si tu l’as installé “par curiosité” plutôt que par besoin réel, tu le vire.
• Désactive la page d’admin publique quand c’est possible. Restreins l’accès par IP ou bastion.
• Bloque ce qui écoute sans raison. Les services inutiles, les APIs ouvertes, les endpoints oubliés.
• Segmente l’appli du reste de l’infra. L’application web doit être dans sa bulle : réseau isolé, DB sur VLAN séparé, pas d’accès direct depuis la DMZ.
• Reverse proxy / WAF / rate limiting : ce sont des protections efficaces, mais le principe reste le même il faut réduire ce qui est visible.
Si tu laisses un compte admin partagé, t’as déjà perdu. Si ton admin a le même mot de passe partout, tu invites le piratage pour le goûter.
• Admins uniques, comptes nominatifs, principe du moindre privilège.
• MFA obligatoire pour les comptes à droit élevé. Pas “optionnel”, obligatoire.
• Interdiction de stocker des secrets dans des fichiers .env accessibles. Utilise des stores de secrets ou un Vault.
• Lockdown des pages sensibles : wp-login, admin, API d’édition. Change l’URL d’administration, limite les tentatives, mets un honeypot si tu veux jouer malin.
• Rotation des credentials et revue périodique des accès. Tenir un inventaire, pas une devinette.
TLS n’est plus une option depuis 2016. Mais HTTPS c’est juste la base : protège en transit et pense au reste.
• TLS 1.3 si possible. HSTS, OCSP stapling, certificats gérés proprement.
• Secrets chiffrés au repos : ne laisse pas les clés ou passwords en clair dans la base, c’est logique mais quand tu vois dans la base de donné de ton site des caracteres chinois poses toi la question.
• Chiffre les backups si elles sortent du périmètre. Sauvegarde chiffrée + contrôle d’accès.
• Sépare les clés de chiffrement hors de la machine applicative (KMS / Vault).
Un site compromis se voit d’abord par un comportement anormal. Mais pour ça, il faut regarder les signaux.
• Logs centralisés et corrélés. Les logs doivent être lus, pas stockés par pitié.
• Alerte sur : créations de comptes, changements de privilèges, modifications de fichiers PHP/TPL, pics de POST hors heures normales.
• Intégrité des fichiers : checksums, alertes quand des fichiers PHP changent.
• Mise en place d’un SIEM ou d’un agent de détection (Wazuh, OSSEC, etc.) selon la taille, si tu nas pas ca ben utilise des vrais outils Wordfense par exemple gratuit mais interessant
• Monitoring uptime + contrôle des erreurs applicatives. Une injection SQL qui renvoie 500 doit déclencher un ticket, pas un SMS au voisin.
Ce n’est pas une question de si, c’est une question de quand. Si tu ne peux pas restaurer en 15 minutes, laisse tomber ta rhétorique “sécurisé”.
• Backups automatisés, testés et hors ligne. Restore test régulier.
• Snapshots rapides pour rollback applicatif, mais backups hors-ligne pour le ransomware.
• Plan de reprise documenté : étapes, contacts, accès d’urgence, procédure de communication.
• Versionning du code et déploiement immuable si possible : rebuild > patch manuel.
Le hardening, ce n’est pas sexy, mais c’est ce qui empêche la catastrophe.
• Mises à jour régulières des CMS, plugins et thèmes. Pas “la semaine prochaine”.
• Permissions fichiers correctes : pas de 777, pas de fichiers uploads exécutables.
• Désactive les fonctions PHP dangereuses si tu n’en as pas besoin.
• Utilise des scans automatisés réguliers (SAST/DAST) et corrige rapidement les findings prioritaires.
• Ia de posture : checklist de déploiement, contrôle des dépendances, suppression des comptes de test.
et puis tu commences a bloquer tout ce que tu peux via le .htaccess tu evites les acces a tes fichiers genre
Order Deny,Allow
Deny from all
ou les modules du style
Header always set X-Frame-Options « SAMEORIGIN »
Header always set X-XSS-Protection « 1; mode=block »
Header always set X-Content-Type-Options « nosniff »
Header always set Referrer-Policy « strict-origin-when-cross-origin »
Header unset X-Powered-By
Header unset Server
Un site sécurisé commence par un backend discipliné.
Les comptes d’administration partagés ou en clair dans un .env ? Non.
Principe du moindre privilège, MFA activé, logs corrélés, alertes sur toute création d’utilisateur.
Et un mot de passe admin réutilisé, c’est un drapeau blanc planté sur ta DMZ.
HTTPS est obligatoire, mais insuffisant.
Les secrets applicatifs doivent être chiffrés au repos, pas juste en transit.
Certbot ne sécurise pas ton serveur, il cache seulement sa vulnérabilité derrière un cadenas vert.
Un site compromis se repère d’abord par un comportement anormal :
– nouveaux fichiers PHP,
– requêtes POST inhabituelles,
– pics de bande passante nocturnes.
Centreon, Zabbix ou Wazuh doivent parler avant que ton client ne t’appelle et Les logs n’ont de valeur que s’ils sont lus.
Ce n’est pas une question de *si*, mais de *quand*.
PRA testé, sauvegardes hors ligne, redéploiement automatisé.
Si tu ne peux pas reconstruire ton site en 15 minutes, il n’est pas sécurisé, il est juste vivant par hasard.
Mon expérience, condensée en une leçon
En 2001 j’affichais fièrement « CRACK THE PLANET » en gros sur la page d’accueil et je balançais du JavaScript non signé comme s’il venait de tomber du ciel. J’étais persuadé que greffer un marquee, un applet et un script copié-collé suffisait à construire un empire. Spoiler : non.
Vingt ans plus tard je conçois des architectures où chaque pièce a sa zone, son journal et sa raison d’exister. Segmentées, journalisées, cloisonnées par design. Pas par paranoia gratuite, mais parce que j’ai appris à faire les comptes après avoir tout pété.
Entre ces deux époques il y a eu une seule vraie progression : l’apprentissage continu par la casse. On casse, on voit ce qui pète, on comprend, on corrige. La curiosité d’un gamin face à un frameset foireux est la même curiosité qu’un ingénieur qui traque une injection SQL sur un SI client. La seule différence, c’est la rigueur. Aujourd’hui je casse moins, j’observe plus, j’automatise la correction, et je documente tout.
Curiosité + erreurs = savoir. Rigueur + automatisation = sécurité.
Ce que ça veut dire concrètement, sans langue de bois
garde la curiosité. Tester, jouer, bricoler : c’est la racine de la compétence.
organise ta curiosité. Chaque test doit être reproductible, journalisé et limité. Pas d’expérimentation sauvage en production.
automatise la répétition. Les correctifs manuels sont des dettes techniques ; transforme-les en playbooks et pipelines CI/CD.
minimise la surface. Moins de code exposé, moins de plugins, moins de vecteurs d’attaque.
surveille et corrèle. Un log brut, c’est de la poussière. Corrèle, alerte, joue la proactivité.
teste tes restores. Un backup non testé n’est qu’un fichier qui te donne mauvaise conscience.
accepte l’obsolescence. Les composants vieillissent, planifie leur rotation et leurs mises à jour.
Si tu appliques ces principes, ton site ne sera pas inviolable. Il sera résilient. Quand ça pète, tu le vois vite, tu sais reconstruire vite, et tu commences l’analyse après avoir remis le service en ligne. Et ça, c’est déjà gagner.
Sécuriser un site, c’est un acte de lucidité.
Ce n’est ni un produit ni une checklist, c’est un état d’esprit : observer, anticiper, documenter, répéter.
Mon ancien site était un chaos créatif, mais il m’a appris une chose essentielle :
> la sécurité ne naît pas du contrôle, mais de la compréhension du désordre.
Et si tu veux vraiment savoir où commence la cybersécurité, regarde d’abord où toi-même tu as laissé des failles.
Malik V.
Références
OWASP Secure Coding Practices – Quick Reference Guide : bonnes pratiques de codage sécurisé.
OWASP Top 10 Web Application Security Risks : liste des risques majeurs pour les applis web.
OWASP Web Security Testing Guide (WSTG) : guide complet de tests de sécurité pour applis web.
“Security on the web” – article de Mozilla Developer Network (MDN) : vue d’ensemble utile pour comprendre les vulnérabilités web.
“11 Best Practices for Developing Secure Web Applications” : article pragmatique listant des points concrets.