Outils de développement · Décodeur JWT
Pourquoi un décodeur JWT n'a besoin d'aucun serveur : vérification avec le panneau réseau
· Comment ça marche
jwt confidentialité traitement du navigateur
Diviser une chaîne et décoder l'url base64 est un travail trivial pour un navigateur, il n'y a donc aucune raison technique pour qu'un décodeur envoie votre jeton n'importe où. Cet article montre comment confirmer qu'un outil le garde local.
Où va mon jeton lorsque j'appuie sur décoder ? — la question à poser à tout outil en ligne
Avant d'utiliser un décodeur en ligne, demandez ce qui reçoit la chaîne après avoir appuyé sur le bouton. Un JWT peut être un identifiant de porteur en direct, donc un téléchargement peut exposer bien plus que des réclamations lisibles. Une page ne doit pas recevoir de jetons de production simplement parce que son interface ressemble à un formateur de texte.
Le propre avertissement de ToolAcre est plus strict qu'une promesse marketing : ne collez pas de jetons de production dans un outil Web, y compris celui-ci. Utilisez un exemple expiré, pivoté ou synthétique. L'implémentation s'exécute localement, mais les extensions du navigateur, les scripts environnants et l'appareil font toujours partie de l'environnement auquel vous devez faire confiance.
Le travail impliqué : fractionnement de chaînes, décodage d'URL base64 et analyse JSON, toutes les fonctionnalités standard du navigateur
Le décodage réel se compose d'opérations de chaîne et de primitives de navigateur. Le code supprime un préfixe Bearer facultatif, le divise en points, normalise l'alphabet base64url, restaure le remplissage, invoque `atob`, convertit les octets via un TextDecoder UTF-8 strict et analyse les deux premiers résultats en tant qu'objets JSON.
Aucune de ces étapes ne nécessite un service à distance. Les lignes NumericDate utilisent l'implémentation locale de Date, les lignes de réclamation sont assemblées à partir de l'objet analysé et la sortie est affectée sous forme de texte. La source n'importe aucune bibliothèque de vérification et ne demande aucune clé secrète ou publique car l'inspection est la seule opération proposée.
Comment vérifier : ouvrez le panneau réseau, collez un jeton, décodez et surveillez les demandes.
Ouvrez les outils de développement avant de saisir des données de test inoffensives, effacez la liste Réseau, effectuez le décodage, puis inspectez les nouvelles requêtes. Recherchez les URL, méthodes et corps de requête pour le jeton ou une sous-chaîne distinctive. Une demande se produisant au même moment ne constitue pas automatiquement un téléchargement ; prouver si les octets d’informations d’identification sont présents.
Gardez le test sous contrôle. Chargez d'abord la page pour que les demandes d'actifs soient satisfaites, utilisez un marqueur synthétique unique dans la charge utile et évitez les véritables informations d'identification. Si le marqueur apparaît dans le corps d'une requête, une URL ou un en-tête, la valeur a quitté le chemin de décodage local. Si ce n’est pas le cas, l’observation prend en charge uniquement cette session.
Une politique de sécurité du contenu stricte restreint les destinations ; cette page charge toujours les scripts divulgués
La page générée comprend une politique de sécurité du contenu dont `connect-src` autorise les destinations soi-même, les objets blob et les données plutôt que les API distantes arbitraires. Cela restreint considérablement les connexions ordinaires initiées par des scripts, mais cela ne justifie pas l’affirmation du plan selon laquelle « il n’y a pas de scripts, de balises ou d’analyses tiers ». Le produit plus large peut charger des scripts Google divulgués.
CSP est une défense en profondeur, et non une preuve que chaque composant exécutable mérite des informations d'identification. Il peut limiter les destinations tandis que les points de terminaison propriétaires restent autorisés et que les extensions fonctionnent sous différents privilèges. Lisez la politique ainsi que les preuves et la source du réseau ; ne réduisez pas ces observations séparées en « rien ne pourra jamais lire ce champ ».
Le décodeur ne stocke aucun jeton, mais un test de rechargement ne peut pas prouver que tous les composants environnants sont inoffensifs.
Le panneau JWT conserve son jeton dans la valeur de l'éditeur et n'appelle pas localStorage ou sessionStorage. Effacer le panneau supprime ses valeurs actuelles et un rechargement ne contient pas de fonctionnalité permettant de restaurer le jeton. Ce fait de source plus restreint soutient une déclaration de non-persistance concernant le panel lui-même.
Un éditeur vierge après rechargement est une preuve utile, mais pas un audit de stockage universel. L'historique du navigateur, les gestionnaires de presse-papiers, les extensions, les captures d'écran et les fonctionnalités du système d'exploitation se trouvent en dehors de ce module. Les contrôles du réseau et du stockage doivent donc être décrits comme des observations reproductibles, et non comme une garantie concernant chaque couche de l'appareil.
Exemple pratique : distinguer le trafic de page ordinaire d'une requête transportant des données de jeton
Pour une vérification réussie, chargez le décodeur JWT de ToolAcre, attendez la fin de l'activité initiale de la page et effacez la liste des demandes. Collez l'échantillon expiré intégré ou un autre jeton non sensible, appuyez sur Décoder et filtrez pour un mot de charge utile unique. Les lignes d’en-tête, de charge utile, de note d’algorithme et de temps doivent apparaître sans requête portant ce marqueur.
Ne qualifiez pas le panneau de « vide » si des demandes d'analyse, de connexion au site ou d'actifs sont visibles. Enregistrez exactement ce qui s'est passé : un trafic de pages ordinaire peut exister, alors qu'aucune demande inspectée n'incluait le jeton synthétique. Cette distinction est une preuve plus solide que le fait de cacher des lignes sans rapport pour donner un aspect absolu à une revendication de confidentialité.
Ce que cela ne couvre pas : les extensions de navigateur et les gestionnaires de presse-papiers, qui échappent au contrôle de la page.
Cette procédure ne peut pas inspecter une extension de navigateur malveillante, l'historique du presse-papiers ou un système d'exploitation compromis. Il ne peut pas non plus prouver ce que fera le code après un futur déploiement. Répétez-le avec la version et l'environnement que vous avez l'intention d'utiliser, et préférez un script local que vous contrôlez lorsque de véritables informations d'identification sont inévitables.
Le panneau Réseau ne convertit pas non plus les affirmations décodées en faits vérifiés. Même lorsque le jeton reste dans l'onglet, ToolAcre ne l'authentifie pas. Le traitement local réduit une voie de divulgation ; il n'établit pas l'intégrité de la signature, l'identité de l'émetteur, l'adéquation au public ou l'autorisation.
Le code ToolAcre local effectue le décodage, mais un jeton actif n'a toujours pas sa place dans un site Web.
ToolAcre effectue sa division, sa conversion d'octets et son analyse JSON dans le code du navigateur, et sa source spécifique à l'outil ne contient aucune opération de téléchargement ou de persistance. Vous pouvez tester ce comportement à l’aide de données synthétiques et d’outils de développement au lieu d’accepter un badge ou un slogan de confidentialité à sa valeur nominale.
Le point à retenir reste conservateur : vérifiez le chemin local, mais gardez les jetons d'accès en direct hors des sites Web. Un outil côté client de décodage uniquement peut être approprié pour les diagnostics jetables ; il ne s'agit pas d'un coffre-fort d'informations d'identification, d'un vérificateur ou d'un service d'autorisation.