Pour utiliser n'importe quel outil Figma tiers, vous générez un Personal Access Token dans les paramètres de Figma et le collez dans l'outil. C'est le minimum requis. Chaque intégration Figma le demande.

Ce que la plupart des gens n'enregistrent pas pleinement : ce token ne lit pas « un fichier ». Il lit chaque fichier auquel votre compte peut accéder. Chaque fichier privé. Chaque bibliothèque organisationnelle. Chaque projet partagé. La portée par défaut d'un PAT Figma est la surface de lecture complète de votre compte.

Pour un designer individuel avec un compte personnel, c'est un risque modéré. Pour un designer senior dans une enterprise avec des bibliothèques de design partagées contenant des produits non publiés, des assets de marque et de l'outillage interne — c'est significatif. Et pour ces designers, « j'ai collé mon token Figma dans cet outil que j'ai trouvé » est un événement de sécurité.

figmascope est conçu pour que cet événement ne se produise pas.

Ce qu'un PAT Figma accorde

L'authentification de l'API Figma est basée sur les PAT. Un token s'authentifie en tant que vous. L'API n'impose pas de portée par fichier au niveau du token — elle impose l'accès aux fichiers sur la base des permissions de votre compte. Si votre compte peut voir un fichier, le PAT peut le lire via l'API.

La portée par défaut du PAT accorde un accès en lecture à :

Figma a introduit un type de token plus ciblé en 2023 — des tokens où vous pouvez sélectionner les portées à accorder. Mais l'interface par défaut propose le token large, et la plupart des tutoriels vous disent de générer un token sans préciser la portée. En pratique, la plupart des PAT qui traînent dans l'historique du presse-papier des designers sont des tokens à lecture complète.

Le modèle de menace pour les outils acceptant des PAT

Un outil qui accepte un PAT Figma et a un backend fait face à une menace spécifique : le backend stocke votre token (pour appeler Figma en votre nom), et ce stockage est une cible. Si le backend est compromis, chaque PAT qui y est stocké est compromis. Si le backend a une fuite de base de données, l'accès Figma de chaque utilisateur est compromis.

Ce n'est pas hypothétique. Des fuites de stockage de tokens OAuth ont touché de nombreux services. Le schéma est : l'utilisateur accorde l'accès, le service stocke le token, le service est compromis, l'attaquant exfiltre les tokens, l'attaquant a maintenant accès à tout ce que ces tokens peuvent atteindre. Pour les tokens Figma dans une enterprise, « tout ce que ces tokens peuvent atteindre » est le système de design complet.

Les outils basés sur un backend doivent résoudre ce problème. Les bons le font : chiffrement au repos, tokens de courte durée, workflows de ré-authentification, journaux d'audit. Le résoudre correctement est un problème d'ingénierie de sécurité de niveau enterprise. La plupart des outils ne le résolvent pas correctement ; ils n'ont simplement pas encore été compromis.

Le stockage de token le plus sécurisé est l'absence de stockage. Si votre architecture ne persiste jamais le token, il n'y a rien à compromettre. C'est le choix architectural que fait figmascope — et ce n'est pas juste une fonctionnalité, c'est l'intégralité du modèle de sécurité.

L'architecture de figmascope

figmascope s'exécute entièrement dans le navigateur. Il n'y a pas de serveur backend. Il n'y a pas de base de données. Il n'y a pas de gestion de session, pas de comptes utilisateur, pas de couche de stockage de tokens. L'application est un bundle statique HTML/CSS/JS servi depuis un CDN. Quand vous l'utilisez, le calcul se produit dans votre onglet navigateur. Rien n'est envoyé aux serveurs de figmascope parce qu'il n'y a pas de serveurs figmascope.

Le flux du PAT fonctionne comme suit :

  1. Vous entrez votre PAT dans le champ de saisie.
  2. La valeur est stockée dans une variable de closure JavaScript — un simple binding let JS à l'intérieur du module de l'application.
  3. Elle n'est jamais écrite dans localStorage. Jamais écrite dans sessionStorage. Jamais définie comme cookie. Jamais écrite dans indexedDB. Jamais envoyée à une URL autre que les deux endpoints de l'API Figma.
  4. Quand vous faites un export, le token est passé comme en-tête X-Figma-Token dans les appels fetch() vers api.figma.com et le CDN Figma pour les assets image.
  5. Quand vous fermez ou rechargez l'onglet, la mémoire JS est libérée. Le token disparaît.

C'est le cycle de vie complet. Pas de persistance nulle part. Pas de transmission réseau sauf directement vers Figma.

Enforcement de la Content Security Policy

Pour rendre la propriété « envoyé uniquement à Figma » applicable plutôt que simplement affirmée, figmascope déploie une Content Security Policy qui verrouille connect-src aux deux hôtes autorisés :

connect-src 'self'
  https://api.figma.com
  https://figma-alpha-api.s3.us-west-2.amazonaws.com;

La CSP est imposée par le navigateur. Même s'il y avait une vulnérabilité d'injection de script dans la page, le navigateur bloquerait toute tentative d'envoyer le token vers un hôte tiers. Les requêtes réseau vers toute autre destination échouent au niveau du navigateur, avant de quitter la machine.

C'est de la défense en profondeur. Le code de l'application n'envoie déjà pas le token ailleurs. La CSP fait en sorte que le code de l'application ne puisse pas l'envoyer ailleurs même s'il essayait.

Chemin de récupération

Parce que le token est uniquement en mémoire, la récupération est triviale : fermez l'onglet. Le token disparaît. Pas d'étape de révocation, pas de « supprimer le compte », pas de « déconnexion ». Onglet fermé = token disparu.

C'est aussi le comportement correct du point de vue de la sécurité opérationnelle. Les fenêtres de credentials de courte durée minimisent l'exposition. Vous ouvrez figmascope, collez votre PAT, faites vos exports, fermez l'onglet. La fenêtre dans laquelle le PAT est accessible est exactement la durée de cette session navigateur. Comparez avec un outil backend où votre token peut être stocké pendant des mois, actif et accessible, jusqu'à ce que vous le révoquez explicitement.

Recommandations indépendamment de l'outil

Même avec l'architecture en mémoire de figmascope, une bonne hygiène PAT importe :

Utilisez un token ciblé. Figma supporte maintenant les tokens avec des portées explicites. Pour les opérations en lecture seule comme les exports figmascope, un token en lecture seule est suffisant et limite le rayon de dommage s'il est jamais exposé. Générez un token avec la portée file_read uniquement, pas la portée large par défaut.

Révoquez les tokens que vous n'utilisez pas activement. Les paramètres de Figma montrent tous les PAT actifs. Les tokens que vous avez générés pour un projet terminé devraient être révoqués. Un token que vous avez généré pour figmascope il y a six mois et que vous n'avez pas utilisé depuis peut être révoqué et régénéré la prochaine fois que vous en avez besoin.

Ne collez jamais des tokens dans des outils avec des backends sans avoir vérifié leur posture de sécurité. Demandez : ce service a-t-il un backend ? Si oui, où et comment stocke-t-il mon token ? Si la réponse n'est pas satisfaisante, ou s'il n'y a pas de réponse, traitez-le comme un risque. Cela s'applique à tous les outils Figma, pas seulement figmascope.

Utilisateurs enterprise : utilisez des comptes partagés/de service là où c'est disponible. Si votre organisation peut créer un compte de service Figma avec un accès en lecture seule à des projets spécifiques, générer des PAT depuis ce compte plutôt que depuis votre compte personnel limite ce qui est accessible à ces projets.

Ce que nous ne prétendons pas

L'architecture navigateur uniquement de figmascope minimise la surface d'attaque pour le vol de credentials côté serveur. Elle n'élimine pas toutes les préoccupations de sécurité :

Nous ne prétendons pas que c'est un substitut à un audit de sécurité de niveau enterprise. Nous prétendons : l'architecture rend une classe spécifique d'attaque — fuite de base de données de tokens côté serveur — structurellement impossible en éliminant le serveur. C'est une réduction significative de la surface d'attaque, pas une immunité complète.

Pourquoi l'open source compte ici

Les affirmations de sécurité ne valent rien sans vérifiabilité. figmascope est sous licence MIT et le code source complet est sur GitHub. Les affirmations de cet article — pas d'écriture dans localStorage, pas de transmission vers un backend, en-têtes CSP — sont toutes vérifiables en lisant le code. Le fichier app.js ne montre pas d'écritures vers les APIs de stockage du navigateur. Le fichier d'en-têtes montre la CSP. Les appels fetch montrent exactement quelles URLs reçoivent le token.

Si nous mentions sur quoi que ce soit de tout cela, il faudrait trente minutes pour trouver le mensonge. C'est le but. L'open source n'est pas juste un choix de licence ; pour un outil qui gère des credentials, c'est la seule base honnête pour une affirmation de sécurité.

Vous devriez vérifier les outils qui gèrent vos credentials. Les outils qui résistent à la vérification sont ceux qui méritent d'être source d'inquiétude.

Une fois que vous êtes satisfait, rendez-vous sur l'application figmascope pour exporter votre bundle de contexte Figma et l'utiliser avec Claude Code ou Cursor.