Qu'est-ce que detektd ?

detektd audite votre app depuis l'extérieur, comme le ferait un attaquant : pas d'accès à votre code, pas de SDK à intégrer, pas d'agent à déployer, pas de credentials cloud à donner. Vous donnez une URL publique, le scan fait le reste en émettant de vraies requêtes HTTP contre elle, exactement comme un navigateur ou un script le ferait.

• Aucune lecture du code source : tout ce qui est trouvé est déduit du trafic réseau, des réponses HTTP, du JS livré au navigateur et des endpoints répondant réellement.
• Aucun accès permanent à votre infra : pas de clé API cloud, pas d'accès base de données, pas de webhook installé dans votre repo.

Le scan classique (passif) est en lecture seule. Le scan actif ajoute des sondes qui écrivent, appellent des RPC et vérifient l'autorisation par utilisateur, avec un compte de test connecté.

• Passif : gratuit, ~2 minutes, aucune identification requise. Couvre en-têtes de sécurité et TLS, secrets exposés, API et bases lisibles sans authentification, CVEs de frameworks et de dépendances, exposition d'infra.
• Actif : réservé aux plans Pro et Studio, nécessite une vérification de propriété du domaine au préalable. Ajoute les tests d'écriture, RPC, CSRF, rate-limit et autorisation par utilisateur (BOLA/IDOR), des classes de faille structurellement invisibles sans compte connecté.

"Scanner de sécurité" est vague ; voici les familles de checks qui tournent réellement à chaque scan, dans le même ordre que le moteur les exécute :

• Secrets & identifiants exposés : clés API, tokens, fichiers .env, clés privées atteignables publiquement.
• En-têtes de sécurité & transport : CSP, HSTS, redirection HTTPS, cookies mal scopés, en-têtes de cache dangereux.
• Bases de données et backends exposés : API, buckets de stockage et backends as a service (Firebase, Supabase, Appwrite...) lisibles ou modifiables sans authentification.
• Auth & autorisation par utilisateur : sessions, et en mode actif, BOLA/IDOR (accéder à la ressource d'un autre utilisateur).
• Dépendances & frameworks : CVEs connues dans les manifests (npm, pip, go...) et les frameworks détectés (Next.js, etc.).
• Exposition d'infrastructure : ports ouverts, panneaux d'admin, bases vectorielles ou de cache exposées, sous-domaines pendants (takeover).
• Supply chain : archives de sources exposées, dépendances suspectes ou typosquattées.
• Surface IA : prompts système exposés, endpoints vulnérables à l'injection de prompt, outils MCP accessibles sans authentification.

Toute application web. Le moteur exécute plus de 190 checks nommés et détecte la stack pour ajouter les modules pertinents : Next.js, React, Vue, Nuxt, Angular, WordPress, Laravel, Django, Firebase, Supabase, un backend maison, etc. Les checks propres à une technologie ne tournent que si elle est détectée ; tout le reste tourne pareil sur chaque site.