Vérificateur de sécurité de site gratuit
Vérifiez les bases de la protection de vos visiteurs : si votre site utilise le HTTPS, si son certificat SSL/TLS est valide et n'est pas sur le point d'expirer, et quels en-têtes de sécurité votre serveur envoie. C'est une vérification rapide de la configuration, pas un test d'intrusion.
Ce que vérifie cet outil
HTTPS
Si la page aboutit sur une adresse https:// après les éventuelles redirections.
Certificat SSL/TLS
Si le certificat est reconnu et correspond à votre domaine, quelle version de TLS est utilisée, qui l'a émis et combien de jours restent avant son expiration.
HSTS
L'en-tête Strict-Transport-Security, qui indique aux navigateurs de toujours utiliser le HTTPS pour votre site.
Content-Security-Policy
Un en-tête qui limite les sources depuis lesquelles les scripts et autres ressources peuvent être chargés, ce qui aide à se protéger du cross-site scripting.
Protection contre le clickjacking
X-Frame-Options, ou une règle frame-ancestors dans votre CSP, qui empêche d'autres sites d'intégrer vos pages de façon invisible.
Autres en-têtes de protection
X-Content-Type-Options, Referrer-Policy et Permissions-Policy.
Divulgation de version
Des en-têtes Server ou X-Powered-By qui révèlent les numéros de version de vos logiciels.
Attributs des cookies
Les cookies définis par la réponse de la page, par nom uniquement : Secure en HTTPS, HttpOnly sur les cookies dont le nom évoque une session ou un jeton, SameSite=None sans Secure, un SameSite manquant, et les cookies rattachés à un domaine parent.
CORS
Une requête supplémentaire avec une Origin fictive et inoffensive (https://rudra-audit.invalid) pour voir si votre serveur renvoie n'importe quelle origine — et s'il autorise aussi les identifiants, ce qui est la combinaison risquée.
Contenu mixte
Des scripts, feuilles de style ou cadres en http:// sur une page HTTPS (contenu mixte actif) et des images ou médias en http:// (passif).
security.txt
Si /.well-known/security.txt existe et contient une ligne Contact et une date Expires dans le futur, pour que les chercheurs sachent comment vous joindre.
Technologies et surface visible
Les frameworks et services reconnaissables dans les en-têtes et le HTML, ainsi que les formulaires de connexion, les URL d'API ou de documentation mentionnées dans la page et les fichiers publics comme robots.txt. Listés à titre informatif ; cela ne coûte aucun point.
Motifs côté client (vérification manuelle)
Les gestionnaires d'événements en ligne comme onclick, et les scripts tiers chargés sans Subresource Integrity. Ce sont des indices peu prioritaires à examiner, pas des vulnérabilités confirmées.
Comment fonctionne la vérification
Nous envoyons une requête normale à votre page, suivons les éventuelles redirections et lisons les en-têtes de la réponse. Nous ouvrons ensuite une connexion TLS distincte vers votre serveur et validons le certificat auprès de la liste standard des autorités de certification de confiance.
Le score part de 100. Ne pas utiliser le HTTPS coûte 40 points ; un en-tête HSTS manquant 15 ; une CSP manquante 12 ; l'absence de protection contre le clickjacking 8 ; un en-tête X-Content-Type-Options manquant 6 ; une Referrer-Policy ou une Permissions-Policy manquante 4 chacune ; et un numéro de version divulgué 3. Un certificat invalide ou expiré coûte 40, un échec de connexion TLS 30, et un certificat qui expire dans les 14 ou 30 jours 10 ou 5.
Le contrôle vérifie la présence des en-têtes, pas la solidité de leurs valeurs — une CSP très permissive compte quand même comme présente. Il ne recherche ni vulnérabilités, ni logiciels obsolètes, ni logiciels malveillants, ni mots de passe faibles, ni réglages de cookies, et n'essaie jamais de pénétrer votre site.
Les éléments que vous verrez
Chaque en-tête est affiché avec sa valeur réelle et une évaluation simple (bon, faible ou absent) ; les constats CSP incluent le tableau des directives analysées ; les constats sur les cookies listent les noms des cookies et leurs attributs, jamais leurs valeurs ; le résultat CORS montre l'origine de test et la réponse obtenue. Chaque constat indique ce que nous attendions, l'URL concernée, le degré de fiabilité du contrôle et sa source — la réponse HTTP, le HTML ou la connexion TLS.
Ce que cet outil ne vérifie pas
Ce n'est pas un test d'intrusion
Aucune exploitation, aucune charge d'attaque, aucune attaque par force brute et aucune recherche de chemins cachés. Il lit la configuration que reçoit n'importe quel navigateur.
Les pages protégées par une connexion
Nous ne nous connectons jamais et n'envoyons jamais d'identifiants : les pages authentifiées, les espaces d'administration et les paramètres de compte ne sont donc pas testés.
Votre code et ses dépendances
Aucun examen du code côté serveur et aucune recherche de vulnérabilités dans votre CMS, vos extensions, vos bibliothèques ou votre logiciel serveur.
Les logiciels malveillants ou un site compromis
Il ne recherche pas de logiciels malveillants, de défiguration, d'injection de spam ni de comptes divulgués.
Tous les cookies utilisés par votre site
Seuls les cookies définis par la réponse de la page elle-même sont vus — pas ceux ajoutés ensuite par JavaScript, d'autres pages ou des tiers. Les valeurs des cookies ne sont jamais lues.
Le comportement de vos formulaires
Les formulaires sont repérés mais jamais envoyés : la validation côté serveur, la protection CSRF et la limitation du débit ne peuvent donc pas être testées.
Problèmes fréquents que nous détectons
HSTS manquant
Très courant, même sur les sites qui redirigent tout vers le HTTPS.
Pas de Content-Security-Policy
L'en-tête le plus souvent absent, car sa mise en place demande un peu de soin.
Pas de protection contre le clickjacking
Ni X-Frame-Options ni règle frame-ancestors.
Certificats proches de l'expiration
Généralement parce que le renouvellement automatique a cessé de fonctionner après un changement de serveur ou de DNS.
Version du serveur visible
Des en-têtes comme « Server: Apache/2.4.41 » ou « X-Powered-By: PHP/7.4 » qui indiquent aux attaquants quoi chercher.
Toujours en HTTP
Pas de HTTPS du tout, ou HTTPS disponible mais sans redirection depuis l'adresse http://.
Cookies de session sans Secure ni HttpOnly
Des cookies de connexion ou de session que des scripts peuvent lire, ou qui pourraient être envoyés en HTTP non chiffré.
Comment les corriger
Définissez les en-têtes là où votre site est servi
Les en-têtes se configurent dans votre serveur web (add_header pour Nginx, Header set pour Apache), votre CDN (par exemple Cloudflare), ou les réglages ou le fichier d'en-têtes de votre hébergeur.
Activez HSTS une fois le HTTPS fonctionnel partout
Commencez par Strict-Transport-Security: max-age=31536000. N'ajoutez includeSubDomains que lorsque tous vos sous-domaines prennent en charge le HTTPS.
Mettez en place la CSP progressivement
Commencez par Content-Security-Policy-Report-Only pour voir ce qui serait bloqué, puis passez en mode appliqué une fois que votre politique autorise tout ce dont le site a besoin.
Ajoutez les en-têtes simples
X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin et X-Frame-Options: DENY (ou SAMEORIGIN) cassent rarement quoi que ce soit.
Automatisez le renouvellement du certificat
Utilisez les certificats gérés par votre hébergeur ou Let's Encrypt avec renouvellement automatique, et vérifiez que la tâche de renouvellement fonctionne toujours après des modifications du serveur.
Masquez les numéros de version
Désactivez l'affichage des versions (par exemple server_tokens off dans Nginx, expose_php = Off dans PHP).
Ajoutez les bons attributs à vos cookies
Donnez l'attribut Secure à chaque cookie sur un site HTTPS, ajoutez HttpOnly aux cookies de session et de connexion, et définissez explicitement SameSite=Lax (ou Strict). SameSite=None nécessite toujours Secure.
Questions fréquentes
S'agit-il d'un test d'intrusion ou d'une analyse de vulnérabilités ?
Non. Il vérifie votre configuration HTTPS, votre certificat et vos en-têtes de sécurité — la configuration visible que reçoit n'importe quel navigateur. Il n'essaie pas de trouver ni d'exploiter des vulnérabilités. Pour cela, faites appel à un testeur de sécurité qualifié.
Peut-il me dire si mon site a été piraté ?
Non. Il ne recherche ni logiciels malveillants, ni pages défigurées, ni comptes compromis. Un bon score signifie seulement que les bases de la sécurité de vos échanges sont configurées.
Évalue-t-il la qualité de mes en-têtes ?
Il vérifie surtout la présence de chaque en-tête. Il reconnaît bien une règle CSP frame-ancestors comme protection contre le clickjacking, mais il n'évalue pas la solidité de vos politiques.
Pourquoi HSTS n'est-il pas vérifié sur mon site en HTTP ?
HSTS n'a d'effet qu'en HTTPS. Si votre site n'est pas en HTTPS, c'est le problème le plus important, et c'est lui qui est signalé à la place.
Ajouter des en-têtes de sécurité peut-il casser mon site ?
La plupart des en-têtes peuvent être ajoutés sans risque. Une Content-Security-Policy peut bloquer des scripts, styles ou contenus intégrés dont votre site dépend : testez-la d'abord en mode report-only.
Le contrôle CORS est-il sans risque pour mon site ?
Oui. Il s'agit d'une seule requête GET ordinaire portant un en-tête Origin pour un domaine qui ne peut pas exister (rudra-audit.invalid). Aucun cookie ni identifiant n'est envoyé et rien n'est modifié ; nous lisons seulement les en-têtes CORS renvoyés.
Pourquoi certains constats sont-ils marqués comme nécessitant une vérification manuelle ?
Des motifs comme les gestionnaires onclick en ligne ou les scripts sans Subresource Integrity peuvent être sans danger ou risqués selon le contexte. Nous les signalons avec une fiabilité faible pour que vous puissiez décider, au lieu de les présenter comme des problèmes confirmés.
Guides utiles
- How to check your website's security: what a passive check can and can't tell youWhat you can safely check about your own site's security in an afternoon, what a passive scanner actually looks at, and where you need a person instead.Lire le guide
- What are security headers? What each one does and how to add themSecurity headers switch on protections built into every browser. What each one does, safe starting values, and how to add them on common servers and platforms.Lire le guide
- Content-Security-Policy explained: directives, unsafe-inline, nonces and a safe rolloutCSP is the most powerful security header and the easiest to get wrong. The directives that matter, how nonces and hashes replace 'unsafe-inline', and a rollout plan that won't break your site.Lire le guide
- How to check cookie security: Secure, HttpOnly, SameSite and cookie prefixesSession cookies are keys to your visitors' accounts. How each cookie attribute protects them, how to inspect your own cookies, and how to set them correctly.Lire le guide
Outils gratuits associés
- Audit de siteVérifiez le SEO, la vitesse, l'affichage mobile, l'accessibilité, la sécurité, les liens cassés et les problèmes de serveur d'une page, dans un seul rapport.Ouvrir Audit de site
- Testeur d'APIEnvoyez une requête à n'importe quel point de terminaison d'API public et consultez le code de statut, le temps de réponse et le succès ou l'échec.Ouvrir Testeur d'API
- Vérificateur SEOVérifiez le titre de votre page, sa description, ses intertitres, les descriptions d'images, l'URL canonique, le robots.txt et le sitemap.Ouvrir Vérificateur SEO
Vous préférez qu'on corrige pour vous ?
Ces contrôles sont gratuits, tout comme les guides. Si vous préférez qu'une personne effectue les modifications, notre équipe propose une aide payante.