Secrets de fournisseurs dans JavaScript
Des identifiants de paiement, IA, cloud ou dépôt peuvent être extraits par tout visiteur.
Secrets exposés côté frontend
Trouvez les identifiants rendus publics par le frontend
BoringSec inspecte ce que reçoit le navigateur, masque les preuves sensibles et ne qualifie pas par défaut les identifiants publics de fuite.
À utiliser après des changements d’environnement, de build, d’intégration ou de déploiement frontend.
Scannez uniquement les systèmes qui vous appartiennent ou pour lesquels vous êtes autorisé. Les moteurs approfondis exigent une autorisation vérifiée et peuvent être indisponibles.
rapport / exemple de constatIllustratif
Critique
Structure d’un exemple de rapport
Clé API serveur exposée dans un bundle
- Preuve
- Un format de secret pris en charge apparaît dans une ressource de même origine ; la valeur est masquée.
- Ce que cela signifie
- Une clé serveur dans le navigateur est récupérable sans authentification.
- Corriger et vérifier
- Révoquez et renouvelez la clé, déplacez les appels côté serveur, redéployez et analysez à nouveau.
Ce constat est illustratif et ne concerne pas votre application. Les rapports réels indiquent le scanner, l’état des preuves et les limites de couverture de la cible.
Scénarios de risque courants
Ce qui mérite une analyse approfondie
Il s’agit de risques pertinents pour les projets exposition de clés API, pas d’affirmations sur chacun d’eux. Un constat apparaît uniquement lorsqu’un scanner fournit une preuve.
Jetons de données privilégiés
Chaînes de connexion, secrets de signature et clés service-role peuvent donner un accès direct.
Faux positifs sur les identifiants publics
Clés publiables et identifiants analytiques exigent une classification par format et contexte.
Couverture transparente
Ce que chaque surface d’analyse peut prouver
L’URL, le code connecté et les moteurs approfondis autorisés répondent à des questions différentes. BoringSec sépare les sources et affiche les états partiels, bloqués ou indisponibles.
Lire la méthodologie publique (en anglais)HTML et bundles publics
Analyse le document et le JavaScript limité de même origine ; les ressources omises restent partielles.
Formats d’identifiants pris en charge
Reconnaît les formats fournisseurs, clés privées, URL de base et jetons backend pris en charge.
Preuve masquée
Affiche la source et une valeur masquée, jamais un identifiant réutilisable.
Exposition propre au dépôt
Le code connecté ajoute les fichiers serveur et identifiants non livrés au navigateur.
De l’observation à la vérification
Un rapport conçu pour l’action suivante
- 01
Observer
Inspectez la réponse publique et lancez les moteurs en arrière-plan applicables.
- 02
Vérifier les preuves
Voyez ce qui a été observé, par quel scanner et avec quel niveau de confiance.
- 03
Corriger en contexte
Utilisez une correction concrète et le contexte pertinent pour Vérificateur de clés API.
- 04
Retester
Lancez une nouvelle évaluation ; la surveillance détecte les régressions ultérieures.
Questions avant l’analyse
BoringSec teste-t-il une clé découverte ?
Non. Il ne s’authentifie jamais auprès d’un tiers avec un identifiant découvert.
NEXT_PUBLIC et VITE sont-ils toujours dangereux ?
Non. Ils désignent des valeurs visibles ; le risque est d’y placer un secret serveur.
Le rapport affiche-t-il la clé complète ?
Non. La preuve est masquée tout en conservant le contexte nécessaire.
Un résultat propre prouve-t-il l’absence de clés ?
Non. Formats non pris en charge, ressources inaccessibles et fichiers serveur restent hors couverture URL.
Contrôlez l’application déployée, puis vérifiez chaque correction
Commencez par l’URL publique. Ajoutez le code ou un contexte authentifié seulement si vous souhaitez étendre la couverture.
Lancer une analyse de sécurité