Comment savoir si ton site est sécurisé en 5 minutes

Pas besoin d'être expert en sécurité pour savoir si ton site a les failles les plus courantes. Avec un navigateur, un terminal et cinq minutes, tu peux vérifier ce qu'un attaquant automatisé teste dans les premières secondes : si le trafic est chiffré, s'il manque des en-têtes, s'il y a des clés dans le code, si ton API accepte des requêtes de n'importe où et s'il y a des fichiers qui ne devraient pas être là. Ce guide t'accompagne pas à pas, avec la commande exacte, ce que signifie chaque résultat et quoi faire selon ce que tu trouves. À la fin, tu as comment prioriser et ce que ce test ne détecte pas.

Minute 1 : HTTPS et redirection

Tape ton domaine avec http:// devant, sans le s. Il doit t'amener à la version https:// immédiatement. Depuis le terminal :

curl -sI http://tondomaine.com | head -3
curl -sI http://tondomaine.com/tarifs | head -3

Les deux réponses doivent être un 301 avec Location: https://.... Si la seconde ne redirige pas, ta redirection ne couvre que l'accueil. Ensuite, avec https://, regarde si l'en-tête Strict-Transport-Security apparaît : il dit au navigateur de ne plus utiliser HTTP. Si tu es sur Vercel, Netlify ou Cloudflare, la redirection est déjà en place et HSTS, c'est à toi de l'ajouter. Ce que signifie chaque détail du certificat, dans ce que signifie vraiment ta note TLS.

Minute 2 : en-têtes de sécurité

curl -sI https://tondomaine.com | grep -iE "strict-transport|content-type-options|frame-options|referrer-policy|content-security-policy|permissions-policy"

Au moins cinq lignes devraient sortir. Chacune qui manque est une protection que le navigateur ne peut pas appliquer : sans X-Frame-Options, ton site peut être intégré dans un autre pour tromper tes utilisateurs ; sans X-Content-Type-Options, le navigateur devine les types de fichiers ; sans Content-Security-Policy, n'importe quel script injecté s'exécute sans frein. Si tu n'aimes pas le terminal, colle ton URL dans l'analyseur d'en-têtes. Le sens de chacun, dans les en-têtes HTTP expliqués pour les humains.

Minute 3 : des secrets dans le JavaScript

Ouvre ton site, clic droit, « Afficher le code source ». Cherche .js pour voir quels fichiers de script il charge, ouvre le principal et utilise la recherche du navigateur avec ces termes :

sk_live   sk_test   service_role   AKIA   eyJhbGci   api_key   apiKey   secret   password

Depuis le terminal, tu peux le faire d'un coup sur tous les scripts de l'accueil :

curl -s https://tondomaine.com/ | grep -oE 'src="[^"]+\.js[^"]*"' | cut -d'"' -f2 | while read s; do
  case "$s" in http*) u="$s";; /*) u="https://tondomaine.com$s";; *) u="https://tondomaine.com/$s";; esac
  curl -s "$u" | grep -oE "sk_live_[A-Za-z0-9]+|service_role|AKIA[A-Z0-9]{16}|eyJhbGciOi[A-Za-z0-9_-]{20,}" | head -3
done

Il y a des choses qu'il est normal de trouver : la clé publique de Stripe (pk_live), la clé anon de Supabase ou la configuration Firebase sont conçues pour aller dans le navigateur. Ce qui ne doit jamais apparaître : sk_live, service_role, des clés AWS (AKIA), des jetons OpenAI ou quoi que ce soit qui s'appelle secret. Si tu en trouves une, considère-la comme compromise et fais-la tourner avant de la retirer du code. La liste complète est dans les secrets que ton appli laisse fuiter dans le navigateur.

Minute 4 : CORS et cookies

CORS décide quels autres sites peuvent faire des requêtes à ton API depuis le navigateur. Demande un de tes endpoints en faisant semblant de venir d'un autre domaine :

curl -sI -H "Origin: https://evil.example" https://tondomaine.com/api/me | grep -i "access-control"

S'il répond Access-Control-Allow-Origin: https://evil.example ou * avec Access-Control-Allow-Credentials: true, n'importe quel site peut lire les données de tes utilisateurs avec leur session. L'origine autorisée doit être la tienne et seulement la tienne. Pendant que tu y es, regarde les cookies dans la réponse de login ou dans les outils du navigateur : ceux de session ont besoin de Secure, HttpOnly et SameSite=Lax ou Strict. Le détail dans CORS mal configuré.

Minute 5 : fichiers exposés

Les outils et les déploiements à moitié finis laissent des traces. Essaie ces chemins et regarde quel code ils renvoient :

for p in .env .env.local .env.production .git/config .DS_Store config.json backup.zip database.sql phpinfo.php server-status api/debug api/seed swagger.json; do
  printf "%-20s " "$p"; curl -s -o /dev/null -w "%{http_code}\n" "https://tondomaine.com/$p"
done

Ce que tu veux voir, c'est 404 (ou 301 vers ta page d'erreur). Un 200 sur .env ou .git/config est grave : le premier contient tes identifiants et le second permet de télécharger le code source complet. Un 200 sur swagger.json ou api/debug n'est pas une fuite en soi, mais il donne à un attaquant la carte de ton API.

Minute bonus : ce que voient les bots

S'il te reste une minute, regarde /robots.txt et /sitemap.xml : qu'ils existent, qu'ils ne bloquent pas tout le monde et que le sitemap ne contienne que des pages que tu veux indexer. Ce n'est pas de la sécurité au sens strict, mais un Disallow: / oublié de la phase de tests coûte des mois de positionnement.

Comment prioriser ce que tu trouves

Tout ne pèse pas pareil. Voici l'ordre que nous utilisons :

Critique, aujourd'hui même. Une clé secrète dans le JavaScript ; .env ou .git accessibles ; une API qui accepte n'importe quelle origine avec des identifiants. Fais tourner, supprime, ferme. Ensuite, vérifie si quelqu'un s'en est servi.
Élevé, cette semaine. Pas de redirection vers HTTPS ; cookies de session sans HttpOnly ou Secure ; routes de débogage en production.
Moyen, ce mois-ci. En-têtes manquants ; pas de HSTS ; certificat qui expire bientôt sans renouvellement automatique.
Faible. Documentation d'API exposée, robots.txt et sitemap négligés, en-têtes qui révèlent la version du serveur.

Ce que ces cinq minutes ne détectent pas

Sois honnête sur les limites. Ce test regarde la surface que n'importe qui peut voir de l'extérieur. Il ne vérifie pas si ta base de données laisse lire les lignes d'autres utilisateurs (sur Supabase c'est le RLS, sur Firebase ce sont les règles), si tes dépendances ont des vulnérabilités connues, si ta logique métier permet de sauter un paiement ou si un formulaire accepte n'importe quelle entrée. Pour le premier point, le guide Supabase et celui de Firebase expliquent comment le tester. Pour le reste, il faut regarder le code, et la checklist avant le lancement rassemble l'essentiel.

Scanaris fait ça et quarante autres choses en 30 secondes

Les cinq étapes ci-dessus sont le cœur de ce que Scanaris vérifie, plus une quarantaine de tests qui ne tiennent pas en cinq minutes : chaque en-tête séparément, les secrets avec des motifs de dizaines de services, les fichiers exposés avec une liste bien plus longue, TLS complet, cookies, CORS sur plusieurs routes, et en plus l'état de ton SEO et de ta visibilité IA. Pour chaque échec, il te donne un fix prompt à coller dans Lovable, Bolt, Cursor ou v0 avec le changement exact, et il peut répéter le scan chaque jour et te prévenir si quelque chose empire. Tout ça, ce sont des vérifications en lecture seule sur ce qui est déjà public sur ton site.

Questions fréquentes

Est-ce légal de scanner mon propre site comme ça ?

Oui. Tout ce qui est ici, ce sont des requêtes normales que n'importe quel navigateur fait ; tu ne fais que lire ce que ton serveur répond déjà à tout le monde. Fais-le uniquement sur tes propres domaines ou avec permission.

Et si je ne sais pas utiliser le terminal ?

Les étapes 1, 3 et 5 peuvent se faire depuis le navigateur (taper des URL et afficher le code source), la 2 avec l'analyseur d'en-têtes gratuit, et la 4 est la seule qui en a besoin. Ou laisse un scanner le faire pour toi.

À quelle fréquence le refaire ?

À chaque déploiement important et, au minimum, une fois par mois. Les applis construites avec l'IA changent vite, et une régénération de code peut réintroduire une faille que tu avais déjà corrigée.