Tech Radar

Tech Radar analyse votre site en lisant le HTML, les en-têtes HTTP, le JavaScript et le CSS pour identifier toutes les technologies utilisées. Il compare ensuite ces technologies aux bases de vulnérabilités connues (CVE), calcule les coûts de maintenance et de licences, et produit un rapport complet.

Oui, l'analyse est entièrement sûre. Nous n'accédons à aucune donnée sensible et n'enregistrons ni mots de passe ni informations confidentielles. Nous n'examinons que des informations publiquement accessibles depuis le frontend de votre site. Les résultats ne sont visibles que par vous et ne sont pas partagés.

Le Tech Health Score est une note de 0 à 100 qui évalue l'état d'ensemble de votre stack technique. Il tient compte des vulnérabilités de sécurité, des technologies obsolètes, des performances et de la complexité de la stack. Plus la note est haute, plus votre site est en bonne santé.

Si le rapport signale des vulnérabilités critiques : 1) contactez immédiatement votre développeur ou votre agence, 2) mettez à jour les technologies vulnérables vers les dernières versions sûres, 3) si la mise à jour est impossible, envisagez de désactiver temporairement la fonctionnalité concernée, 4) évaluez une migration vers des plateformes plus sûres comme Bsite. Nous pouvons vous aider avec une consultation gratuite.

Le XSS est une faille qui permet d'injecter du code JavaScript malveillant dans des pages consultées par d'autres utilisateurs. Elle peut mener au vol de cookies de session, d'identifiants, ou à l'exécution d'actions non autorisées. On s'en protège en validant et en assainissant toutes les entrées utilisateur et en utilisant une Content Security Policy (CSP).

L'injection SQL exploite des entrées non validées pour exécuter des requêtes SQL arbitraires sur la base de données. Elle peut mener au vol, à la modification ou à la suppression d'informations sensibles. La défense principale consiste à utiliser des requêtes préparées, à valider strictement les entrées et à appliquer le moindre privilège aux comptes de la base.

Le CSRF force un utilisateur authentifié à effectuer des actions qu'il n'a pas voulues sur une application web. L'attaquant amène la victime à cliquer sur un lien ou à visiter une page malveillante qui envoie des requêtes au site cible avec les identifiants de la victime. On s'en protège avec des jetons CSRF uniques par session et en vérifiant l'origine des requêtes.

La RCE est l'une des failles les plus graves : elle permet d'exécuter du code arbitraire sur le serveur. Elle peut mener au contrôle complet du système, au vol de données, à l'installation de logiciels malveillants ou à l'usage du serveur pour attaquer d'autres systèmes. On s'en protège en gardant les logiciels à jour, en validant les entrées, en limitant les privilèges d'exécution et en utilisant le sandboxing.

Le DDoS (déni de service distribué) sature un site de trafic venu de plusieurs sources à la fois et le rend inaccessible. Les attaquants utilisent des botnets, des réseaux d'ordinateurs compromis, pour générer des requêtes en masse. La défense passe par un CDN avec protection DDoS, la limitation de débit, un pare-feu applicatif (WAF) et la surveillance du trafic anormal.

On parle de MITM quand un attaquant intercepte la communication entre deux parties pour l'espionner ou en modifier le contenu. Cela arrive sur des réseaux WiFi publics non sécurisés ou via un empoisonnement DNS. La défense principale : HTTPS avec des certificats valides, HSTS (HTTP Strict Transport Security), éviter les réseaux non sécurisés et vérifier les certificats SSL.

Les technologies sur lesquelles le site est construit, lues dans les en-têtes, le balisage et les ressources chargées : serveur, framework, système de gestion de contenu, outils de mesure et bibliothèques, avec leur version quand elle est visible.

Une entrée Common Vulnerabilities and Exposures est l'identifiant public d'une faille de sécurité connue. Confronter les versions trouvées à ce catalogue indique quels problèmes déjà publiés pourraient concerner le site.

Pas à elle seule. Le rapprochement se fait sur la version déclarée, qui peut être fausse, et un correctif est souvent appliqué sans que la chaîne de version change. C'est un point de départ pour vérifier, pas un verdict.

Sur l'un de nos serveurs, et nous le disons clairement car c'est l'un des rares outils qui ne peut pas fonctionner dans le navigateur : le traitement a besoin d'une vraie machine. Le fichier est téléversé, traité, puis supprimé automatiquement sous une heure. Personne ne l'ouvre, il ne finit dans aucune archive et il ne sert jamais à entraîner quoi que ce soit.

Non. Le fichier fait ce que vous avez demandé puis disparaît : nous ne le relions pas à vous, nous ne le revendons pas, nous ne le transmettons à personne et nous n'entraînons aucun modèle dessus. La plupart des autres outils Binatomy ne téléversent rien du tout ; celui-ci est l'un des rares qui ne peut pas faire autrement.

Nous ne vous profilons pas : aucun compte à créer, nous ne demandons jamais votre e-mail pour utiliser un outil, et nous ne gardons aucun profil de ce que vous faites. Nous sommes une société italienne et nous travaillons sous le RGPD et les autres règles européennes, avec la politique de confidentialité et la demande de consentement bien visibles. Une chose que nous disons en entier plutôt que de la cacher derrière un slogan : les publicités de la page sont celles de Google, et Google peut utiliser des cookies pour les personnaliser. Vous décidez depuis la bannière de consentement : si vous refusez, les publicités restent mais ne sont pas personnalisées, et l'outil fonctionne exactement pareil.

Avec les publicités de la page, et rien d'autre. Nous ne vendons pas vos données, il n'y a pas d'offre payante cachée, pas de limite qui finit par réclamer votre carte, et aucune inscription. Les publicités payent les serveurs et le temps que nous passons à écrire les outils : c'est ce qui nous permet de les laisser ouverts à tous.