Per usare qualsiasi strumento Figma di terze parti, generi un Personal Access Token nelle impostazioni di Figma e lo incolli nello strumento. Questo è il minimo indispensabile. Ogni integrazione Figma lo chiede.

Quello che la maggior parte delle persone non registra completamente: quel token non legge "un file." Legge ogni file a cui il tuo account può accedere. Ogni file privato. Ogni libreria organizzativa. Ogni progetto condiviso. Lo scope predefinito di un PAT Figma è l'intera superficie di lettura del tuo account.

Per un designer individuale con un account personale, questo è un rischio moderato. Per un designer senior in un'azienda con librerie di design condivise contenenti prodotti non ancora rilasciati, asset del brand e strumenti interni — è significativo. E per quei designer, "ho incollato il mio token Figma in questo strumento che ho trovato" è un evento di sicurezza.

figmascope è progettato in modo che quell'evento non accada.

Cosa concede un PAT Figma

L'autenticazione dell'API di Figma è basata su PAT. Un token si autentica come te. L'API non applica lo scoping per file a livello di token — applica l'accesso ai file in base ai permessi del tuo account. Se il tuo account può visualizzare un file, il PAT può leggerlo tramite l'API.

Lo scope PAT predefinito concede accesso in lettura a:

Figma ha introdotto un tipo di token più scoped nel 2023 — token dove puoi selezionare quali scope concedere. Ma l'interfaccia predefinita è il token ampio, e la maggior parte dei tutorial ti dice di generare un token senza specificare lo scope. In pratica, la maggior parte dei PAT che circolano nella cronologia degli appunti dei designer sono token con accesso completo in lettura.

Il modello di minaccia per gli strumenti che accettano PAT

Uno strumento che accetta un PAT Figma e ha un backend affronta una minaccia specifica: il backend memorizza il tuo token (per chiamare Figma per conto tuo), e quella storage è un bersaglio. Se il backend viene compromesso, ogni PAT memorizzato lì è compromesso. Se il backend ha una violazione del database, l'accesso Figma di ogni utente è violato.

Questo non è ipotetico. Le violazioni di storage di token OAuth sono accadute a molti servizi. Lo schema è: l'utente concede l'accesso, il servizio memorizza il token, il servizio viene violato, l'attaccante esfiltra i token, l'attaccante ora ha accesso a tutto ciò a cui quei token possono accedere. Per i token Figma in un'azienda, "tutto ciò a cui quei token possono accedere" è l'intero design system.

Gli strumenti basati su backend devono risolvere questo problema. I migliori lo fanno: crittografia a riposo, token a breve durata, flussi di riautenticazione, log di audit. Risolverlo correttamente è un problema di ingegneria della sicurezza a livello enterprise. La maggior parte degli strumenti non lo risolve correttamente; semplicemente non sono ancora stati violati.

Il storage di token più sicuro è nessun storage. Se la tua architettura non persiste mai il token, non c'è nulla da violare. Questa è la scelta architetturale che fa figmascope — e non è solo una funzionalità, è l'intero modello di sicurezza.

L'architettura di figmascope

figmascope gira interamente nel browser. Non c'è nessun server backend. Non c'è nessun database. Non c'è nessuna gestione delle sessioni, nessun account utente, nessun layer di storage dei token. L'applicazione è un bundle statico HTML/CSS/JS servito da una CDN. Quando lo usi, il calcolo avviene nella tua scheda browser. Nulla viene inviato ai server di figmascope perché non ci sono server di figmascope.

Il flusso del PAT funziona così:

  1. Inserisci il tuo PAT nel campo di input.
  2. Il valore viene memorizzato in una variabile di chiusura JavaScript — un normale binding let JS all'interno del modulo applicativo.
  3. Non viene mai scritto in localStorage. Mai scritto in sessionStorage. Mai impostato come cookie. Mai scritto in indexedDB. Mai inviato a nessun URL diverso dai due endpoint dell'API Figma.
  4. Quando esegui un'esportazione, il token viene passato come header X-Figma-Token nelle chiamate fetch() a api.figma.com e alla CDN Figma per gli asset immagine.
  5. Quando chiudi o ricarichi la scheda, la memoria JS viene rilasciata. Il token è scomparso.

Questo è il ciclo di vita completo. Nessuna persistenza da nessuna parte. Nessuna trasmissione di rete tranne direttamente a Figma.

Applicazione della Content Security Policy

Per rendere la proprietà "inviato solo a Figma" verificabile piuttosto che semplicemente dichiarata, figmascope distribuisce una Content Security Policy che blocca connect-src ai due host consentiti:

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

La CSP è applicata dal browser. Anche se ci fosse una vulnerabilità di iniezione di script nella pagina, il browser bloccherebbe qualsiasi tentativo di inviare il token a un host di terze parti. Le richieste di rete verso qualsiasi altra destinazione falliscono a livello di browser, prima di lasciare il dispositivo.

Questa è difesa in profondità. Il codice dell'applicazione già non invia il token da nessun'altra parte. La CSP fa sì che il codice dell'applicazione non possa inviarlo da nessun'altra parte anche se ci provasse.

Percorso di recupero

Poiché il token è solo in memoria, il recupero è banale: chiudi la scheda. Il token è scomparso. Nessun passaggio di revoca, nessun "elimina account," nessun "disconnetti." Scheda chiusa = token scomparso.

Questo è anche il comportamento corretto dal punto di vista della sicurezza operativa. Le finestre di credenziali a breve durata minimizzano l'esposizione. Apri figmascope, incolla il tuo PAT, esegui le esportazioni, chiudi la scheda. La finestra in cui il PAT è accessibile è esattamente la durata di quella sessione browser. Contrasta questo con uno strumento backend dove il tuo token potrebbe essere memorizzato per mesi, attivo e accessibile, fino a quando non lo revochi esplicitamente.

Raccomandazioni indipendentemente dallo strumento

Anche con l'architettura in-memory di figmascope, una buona igiene del PAT è importante:

Usa un token scoped. Figma ora supporta token con scope espliciti. Per operazioni in sola lettura come le esportazioni figmascope, un token in sola lettura è sufficiente e limita il raggio di esplosione se viene mai esposto. Genera un token con solo lo scope file_read, non lo scope ampio predefinito.

Revoca i token che non usi attivamente. Le impostazioni di Figma mostrano tutti i PAT attivi. I token che hai generato per un progetto terminato dovrebbero essere revocati. Un token che hai generato per figmascope sei mesi fa e non hai usato da allora può essere revocato e rigenerato la prossima volta che ne hai bisogno.

Non incollare mai token in strumenti con backend a meno che non tu abbia verificato la loro posizione di sicurezza. Chiediti: questo servizio ha un backend? Se sì, dove e come memorizza il mio token? Se la risposta non è soddisfacente, o se non c'è nessuna risposta, trattala come un rischio. Questo si applica a ogni strumento Figma, non solo a figmascope.

Utenti enterprise: usa account condivisi/di servizio dove disponibile. Se la tua organizzazione può creare un account di servizio Figma con accesso in sola lettura a progetti specifici, generare PAT da quell'account piuttosto che dal tuo account personale limita ciò che è accessibile a quei progetti.

Cosa non affermiamo

L'architettura solo-browser di figmascope minimizza la superficie di attacco per il furto di credenziali lato server. Non elimina tutte le preoccupazioni di sicurezza:

Non stiamo affermando che questo sia un sostituto per un audit di sicurezza a livello enterprise. Stiamo affermando: l'architettura rende una specifica classe di attacco — violazione del database di token lato server — strutturalmente impossibile eliminando il server. Questa è una riduzione significativa della superficie di attacco, non un'immunità completa.

Perché l'open source è importante qui

Le affermazioni di sicurezza sono prive di valore senza verificabilità. figmascope è con licenza MIT e il codice sorgente completo è su GitHub. Le affermazioni in questo articolo — nessuna scrittura in localStorage, nessuna trasmissione al backend, header CSP — sono tutte verificabili leggendo il codice. Il file app.js non mostra nessuna scrittura alle API di storage del browser. Il file degli header mostra la CSP. Le chiamate fetch mostrano esattamente quali URL ricevono il token.

Se stessimo mentendo su qualcosa di questo, ci vorrebbero trenta minuti per trovare la bugia. Questo è il punto. L'open source non è solo una scelta di licenza; per uno strumento che gestisce credenziali, è l'unica base onesta per un'affermazione di sicurezza.

Dovresti verificare gli strumenti che gestiscono le tue credenziali. Gli strumenti che resistono alla verifica sono quelli di cui vale la pena preoccuparsi.

Una volta soddisfatto, vai all'app figmascope per esportare il tuo bundle di contesto Figma e usarlo con Claude Code o Cursor.