Couverture d'audit complète
Tout ce que nous vérifions — les 22.
Une URL. Aucune installation. NullShield exécute chaque contrôle ci-dessous contre votre site en production, puis vous montre le résultat de chacun — y compris ceux que vous réussissez déjà. C'est toute la méthodologie, à découvert.
Déterministe et mappé à l'OWASP Top 10:2025 — le même site obtient la même note à chaque fois.
Sécurité du transport
4 contrôlesComment le trafic vers votre site est chiffré et protégé en transit.
Certificat TLS / SSL
Ce que nous vérifions : Nous ouvrons une connexion HTTPS en direct et inspectons le certificat — validité, émetteur et date d'expiration.
Pourquoi c'est important : Un certificat invalide, expiré ou non fiable fait que les navigateurs avertissent vos visiteurs et détruit la confiance instantanément.
Versions du protocole TLS
Ce que nous vérifions : Nous testons activement si le serveur accepte encore les protocoles obsolètes TLS 1.0 et TLS 1.1.
Pourquoi c'est important : Les anciennes versions de TLS ont des faiblesses connues et échouent à la conformité moderne (PCI DSS, durcissement de base).
Robustesse HSTS
Ce que nous vérifions : Si l'en-tête HTTP Strict Transport Security est présent, nous évaluons son max-age, includeSubDomains et sa préparation au preload.
Pourquoi c'est important : Une politique HSTS faible laisse une fenêtre ouverte aux attaques par rétrogradation et au vol de cookies lors de la première visite.
Redirection HTTPS
Ce que nous vérifions : Nous demandons la version HTTP du site et vérifions qu'elle force le passage à HTTPS.
Pourquoi c'est important : Sans redirection, les visiteurs et les moteurs de recherche peuvent atterrir sur la version non chiffrée du site.
En-têtes de sécurité
2 contrôlesLes en-têtes HTTP qui indiquent au navigateur comment protéger vos visiteurs.
En-têtes de sécurité HTTP
Ce que nous vérifions : Nous vérifions l'ensemble complet des en-têtes de protection — HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy et les en-têtes d'isolation cross-origin.
Pourquoi c'est important : Ces en-têtes sont la défense la moins chère et la plus efficace contre le clickjacking, le MIME sniffing et les fuites de données.
Content Security Policy
Ce que nous vérifions : Si une CSP est définie, nous évaluons sa qualité — unsafe-inline, unsafe-eval, sources génériques et directives manquantes.
Pourquoi c'est important : Une CSP permissive donne un faux sentiment de sécurité ; une CSP stricte est la meilleure défense contre le cross-site scripting (XSS).
Cookies et sessions
1 contrôlesSi les cookies que votre site définit sont protégés contre le vol et l'abus.
Attributs des cookies
Ce que nous vérifions : Nous inspectons chaque cookie défini par le site pour les attributs Secure, HttpOnly et SameSite.
Pourquoi c'est important : Les cookies de session sans ces attributs peuvent être volés sur le réseau ou par un script malveillant, permettant le détournement de compte.
Intégrité du frontend et du contenu
4 contrôlesLes scripts, bibliothèques et le HTML servis aux navigateurs des visiteurs.
Contenu de la page et formulaires
Ce que nous vérifions : Nous analysons le HTML rendu pour le contenu mixte (HTTP) et les formulaires soumis sans protection CSRF.
Pourquoi c'est important : Le contenu mixte casse silencieusement le chiffrement, et les formulaires non protégés invitent au cross-site request forgery.
Subresource Integrity
Ce que nous vérifions : Nous listons les scripts et styles tiers chargés sans hachage d'intégrité (SRI).
Pourquoi c'est important : Si un CDN dont vous dépendez est compromis, c'est précisément SRI qui empêche l'exécution du code de l'attaquant sur votre site.
Source maps exposées
Ce que nous vérifions : Nous testons si vos source maps JavaScript sont accessibles publiquement.
Pourquoi c'est important : Des source maps publiées livrent à un attaquant votre code source original et commenté — y compris la logique que vous vouliez cacher.
Bibliothèques JavaScript obsolètes
Ce que nous vérifions : Nous identifions les bibliothèques frontend et signalons les versions en fin de vie (ancien jQuery, Bootstrap, AngularJS, Moment.js).
Pourquoi c'est important : Les bibliothèques non maintenues accumulent des vulnérabilités publiques non corrigées que les bots recherchent activement.
Fuites de données et d'informations
4 contrôlesLes fichiers, chemins et messages d'erreur que le public ne devrait jamais voir.
Chemins sensibles exposés
Ce que nous vérifions : Nous testons en toute sécurité une vingtaine de chemins à risque — .env, .git, fichiers de configuration, stockage d'identifiants et panneaux d'administration.
Pourquoi c'est important : Un seul fichier .env ou répertoire .git accessible peut divulguer des mots de passe de base de données, des clés API et tout votre code.
Listage de répertoires
Ce que nous vérifions : Nous vérifions les dossiers courants pour des pages d'index générées automatiquement qui exposent leur contenu.
Pourquoi c'est important : Un listage de répertoires ouvert permet à quiconque de parcourir et télécharger des fichiers que vous n'avez jamais voulu publier.
Fuites d'erreurs et de débogage
Ce que nous vérifions : Nous déclenchons un état d'erreur et recherchons des traces de pile et des sorties de débogage d'ASP.NET, PHP, Python ou de la base de données.
Pourquoi c'est important : Des erreurs détaillées livrent à un attaquant votre framework, vos chemins de fichiers et vos requêtes — un guide pour l'attaque suivante.
Fuites de versions et de bannières
Ce que nous vérifions : Nous lisons les en-têtes d'identification (Server, X-Powered-By, X-AspNet-Version) pour les noms de logiciels et les numéros de version.
Pourquoi c'est important : Exposer des versions exactes permet à un attaquant d'associer votre stack à des exploits connus en quelques secondes.
Configuration du serveur et de l'API
4 contrôlesComment votre serveur répond aux requêtes et ce qu'il révèle de lui-même.
Méthodes HTTP
Ce que nous vérifions : Nous vérifions les méthodes que le serveur propose et testons la dangereuse méthode TRACE.
Pourquoi c'est important : Les méthodes dangereuses et TRACE permettent le cross-site tracing et des écritures non voulues dans votre application.
Fichiers de politique cross-domain
Ce que nous vérifions : Nous vérifions les fichiers crossdomain.xml et clientaccesspolicy.xml trop permissifs.
Pourquoi c'est important : Une politique cross-domain générique permet au code de sites étrangers de lire des réponses destinées uniquement à vos utilisateurs.
Configuration CORS
Ce que nous vérifions : Nous testons votre politique CORS pour les origines génériques, les origines reflétées et l'accès avec identifiants.
Pourquoi c'est important : Une politique CORS mal configurée peut permettre à n'importe quel site de lire vos réponses d'API authentifiées au nom du visiteur.
Introspection GraphQL
Ce que nous vérifions : Nous testons les points de terminaison GraphQL courants pour voir si l'introspection du schéma est publiquement accessible.
Pourquoi c'est important : Une introspection ouverte cartographie toute votre API — chaque type, champ et mutation — pour que l'attaquant l'étudie.
E-mail et domaine (DNS)
1 contrôlesLes enregistrements DNS qui empêchent l'usurpation de votre domaine et de vos e-mails.
Enregistrements e-mail et DNS
Ce que nous vérifions : Nous résolvons les enregistrements DNS du domaine — SPF, DKIM, DMARC, DNSSEC et CAA.
Pourquoi c'est important : L'absence de SPF/DKIM/DMARC signifie que n'importe qui peut envoyer un e-mail qui semble provenir de votre domaine.
Hygiène de publication
2 contrôlesDe petits fichiers attendus qui signalent qu'un site est géré professionnellement.
robots.txt
Ce que nous vérifions : Nous récupérons le robots.txt et vérifions qu'il est présent et ne révèle pas accidentellement de chemins sensibles.
Pourquoi c'est important : Un robots.txt sensé guide les moteurs de recherche ; un robots.txt négligent peut exposer exactement les chemins que vous vouliez cacher.
security.txt
Ce que nous vérifions : Nous cherchons /.well-known/security.txt avec des champs Contact et Expires valides (RFC 9116).
Pourquoi c'est important : Un security.txt donne aux chercheurs un moyen de vous signaler une vulnérabilité au lieu de la rendre publique.
Voyez votre propre rapport en 60 secondes.
Chaque contrôle ci-dessus, exécuté contre votre site, avec le correctif exact pour tout ce qui échoue — et une nouvelle analyse dans 14 jours pour prouver l'amélioration.
Analyser mon site — 49 $/moisRésiliation en deux clics · sans engagement