Om een extern Figma-gereedschap te gebruiken, genereer je een Persoonlijk Toegangstoken in de Figma-instellingen en plak je het in het gereedschap. Dit is de standaard. Elke Figma-integratie vraagt erom.
Wat de meeste mensen niet volledig beseffen: die token leest niet "één bestand." Het leest elk bestand waartoe je account toegang heeft. Elk privébestand. Elke organisatiebibliotheek. Elk gedeeld project. De standaard scope van een Figma PAT is het volledige leesoppervlak van je account.
Voor een individuele ontwerper met een persoonlijk account is dat een matig risico. Voor een vaste ontwerper bij een onderneming met gedeelde ontwerpbibliotheken die niet-uitgebrachte producten, merkactiva en interne tools bevatten — is het significant. En voor die ontwerpers is "ik plakte mijn Figma-token in dit gereedschap dat ik vond" een beveiligingsincident.
figmascope is ontworpen zodat dat incident niet gebeurt.
Wat een Figma PAT verleent
De API-authenticatie van Figma is PAT-gebaseerd. Een token authentiseert als jou. De API dwingt geen per-bestand-scoping af op tokenniveau — het handhaaft bestandstoegang op basis van de machtigingen van je account. Als je account een bestand kan bekijken, kan de PAT het lezen via de API.
De standaard PAT-scope verleent leestoegang tot:
- Alle bestanden die je hebt aangemaakt
- Alle bestanden die met je zijn gedeeld
- Alle bestanden in projecten en teams waarvan je lid bent
- Gepubliceerde componentbibliotheken die je team gebruikt
Figma introduceerde in 2023 een meer geschopt tokentype — tokens waarbij je kunt selecteren welke scopes je verleent. Maar de UI is standaard ingesteld op de brede token, en de meeste tutorials vertellen je een token te genereren zonder scope te specificeren. In de praktijk zijn de meeste PAT's die rondzweven in de klembordgeschiedenis van ontwerpers volledige-lees-tokens.
Het bedreigingsmodel voor PAT-accepterende tools
Een gereedschap dat een Figma PAT accepteert en een backend heeft, staat voor een specifieke bedreiging: de backend slaat je token op (om namens jou Figma aan te roepen), en die opslag is een doelwit. Als de backend wordt gecompromitteerd, is elke PAT die daar is opgeslagen gecompromitteerd. Als de backend een databaselek heeft, is de Figma-toegang van elke gebruiker lek.
Dit is niet hypothetisch. OAuth-tokenopslaglekken zijn bij veel diensten gebeurd. Het patroon is: gebruiker verleent toegang, dienst slaat token op, dienst wordt gehackt, aanvaller extraheert tokens, aanvaller heeft nu toegang tot alles wat die tokens kunnen bereiken. Voor Figma-tokens bij een onderneming is "alles wat die tokens kunnen bereiken" het volledige ontwerpsysteem.
Backendgebaseerde tools moeten dit probleem oplossen. De goede oplossen het: versleuteling in rust, kortlevende tokens, herauthenticatieworkflows, auditlogging. Het goed oplossen is een beveiligingsengineeringprobleem op enterpriseniveau. De meeste tools lossen het niet goed op; ze zijn gewoon nog niet gehackt.
De veiligste tokenopslag is helemaal geen opslag. Als je architectuur de token nooit persistent maakt, is er niets te hacken. Dit is de architecturele keuze die figmascope maakt — en het is niet alleen een functie, het is het volledige beveiligingsmodel.
De architectuur van figmascope
figmascope draait volledig in de browser. Er is geen backendserver. Er is geen database. Er is geen sessiebeheer, geen gebruikersaccounts, geen tokenopslaglaag. De applicatie is een statische HTML/CSS/JS-bundel die wordt geserveerd vanaf een CDN. Wanneer je het gebruikt, vindt berekening plaats in je browsertabblad. Er wordt niets naar figmascope-servers gestuurd omdat er geen figmascope-servers zijn.
De PAT-stroom werkt als volgt:
- Je voert je PAT in het invoerveld in.
- De waarde wordt opgeslagen in een JavaScript-sluitingsvariabele — een gewone JS
let-binding binnen de applicatiemodule. - Het wordt nooit geschreven naar
localStorage. Nooit geschreven naarsessionStorage. Nooit ingesteld als cookie. Nooit geschreven naarindexedDB. Nooit verzonden naar een andere URL dan de twee Figma API-eindpunten. - Wanneer je een export maakt, wordt het token doorgegeven als de
X-Figma-Token-header infetch()-aanroepen naarapi.figma.comen de Figma CDN voor afbeeldingsactiva. - Wanneer je het tabblad sluit of herlaadt, wordt het JS-geheugen vrijgegeven. Het token is weg.
Dit is de volledige levenscyclus. Nergens persistentie. Geen netwerktransmissie behalve direct naar Figma.
Content Security Policy-handhaving
Om de eigenschap "alleen naar Figma verzonden" handhaafbaar te maken in plaats van alleen beweerd, implementeert figmascope een Content Security Policy die connect-src vergrendelt op de twee toegestane hosts:
connect-src 'self'
https://api.figma.com
https://figma-alpha-api.s3.us-west-2.amazonaws.com;
CSP wordt door de browser gehandhaafd. Zelfs als er een scriptinjectiekwetsbaarheid in de pagina zou zijn, zou de browser elke poging blokkeren om het token naar een externe host te sturen. Netwerkaanvragen naar een andere bestemming mislukken op browserniveau, voordat ze de machine verlaten.
Dit is verdediging in de diepte. De applicatiecode stuurt het token al nergens anders heen. De CSP zorgt ervoor dat applicatiecode het nergens anders heen kan sturen, zelfs als het dat probeerde.
Herstelpad
Omdat het token alleen in het geheugen zit, is herstel triviaal: sluit het tabblad. Het token is weg. Geen intrekkingsstap, geen "account verwijderen," geen "uitloggen." Tabblad gesloten = token weg.
Dit is ook het juiste gedrag vanuit een operationeel beveiligingsperspectief. Kortlevende referentievensters minimaliseren blootstelling. Je opent figmascope, plakt je PAT, doet je exports, sluit het tabblad. Het venster waarin de PAT toegankelijk is, is precies de duur van die browsersessie. Vergelijk dit met een backendgereedschap waarbij je token mogelijk maanden wordt opgeslagen, actief en toegankelijk, totdat je het expliciet intrekt.
Aanbevelingen ongeacht het gereedschap
Zelfs met de in-memory-architectuur van figmascope is goede PAT-hygiëne belangrijk:
Gebruik een geschopte token. Figma ondersteunt nu tokens met expliciete scopes. Voor alleen-lezen-bewerkingen zoals figmascope-exports is een alleen-lezen-token voldoende en beperkt de schaderadius als het ooit wordt blootgesteld. Genereer een token met alleen file_read-scope, niet de standaard brede scope.
Trek tokens in die je niet actief gebruikt. De instellingen van Figma tonen alle actieve PAT's. Tokens die je hebt gegenereerd voor een project dat is beëindigd, moeten worden ingetrokken. Een token die je zes maanden geleden voor figmascope hebt gegenereerd en sindsdien niet meer hebt gebruikt, kan worden ingetrokken en opnieuw worden gegenereerd de volgende keer dat je het nodig hebt.
Plak nooit tokens in tools met backends tenzij je hun beveiligingspositie hebt geverifieerd. Vraag: heeft deze dienst een backend? Zo ja, waar en hoe slaat het mijn token op? Als het antwoord niet bevredigend is, of als er geen antwoord is, behandel het dan als een risico. Dit geldt voor elk Figma-gereedschap, niet alleen figmascope.
Enterprisegebruikers: gebruik gedeelde/serviceaccounts waar beschikbaar. Als je organisatie een Figma-serviceaccount kan aanmaken met alleen-lezen-toegang tot specifieke projecten, beperkt het genereren van PAT's vanuit dat account in plaats van je persoonlijke account wat toegankelijk is tot die projecten.
Wat we niet beweren
De alleen-browser-architectuur van figmascope minimaliseert het aanvalsoppervlak voor serverzijdig referentiediefstal. Het elimineert niet alle beveiligingszorgen:
- Browserextensies met brede machtigingen kunnen JavaScript-variabelen lezen. Als je niet-vertrouwde browserextensies hebt, vertegenwoordigen ze een risico voor elke referentie die je in een webapplicatie invoert.
- Een gecompromitteerde browser (malware, XSS op een andere pagina die isolatie omzeilt) zou mogelijk in-tab-geheugen kunnen lezen, hoewel moderne browser-sandboxing cross-origin-toegang zeer moeilijk maakt.
- Schermdelen en meekijken over de schouder vallen buiten de scope van elke architectuur.
We beweren niet dat dit een vervanging is voor enterprise-grade beveiligingscontrole. We beweren: de architectuur maakt een specifieke klasse van aanval — serverzijdige tokensdatabaselek — structureel onmogelijk door de server te elimineren. Dat is een betekenisvolle vermindering van het aanvalsoppervlak, geen volledige immuniteit.
Waarom open source hier belangrijk is
Beveiligingsclaims zijn waardeloos zonder verifieerbaarheid. figmascope is MIT-gelicenseerd en de volledige broncode staat op GitHub. De claims in dit artikel — geen localStorage-schrijfacties, geen backendtransmissie, CSP-headers — zijn allemaal verifieerbaar door de code te lezen. De app.js toont geen schrijfacties naar browser-opslag-API's. Het headers-bestand toont de CSP. De fetch-aanroepen tonen precies welke URL's het token ontvangen.
Als we over een van deze dingen zouden liegen, zou het dertig minuten kosten om de leugen te vinden. Dat is het punt. Open source is niet alleen een licentiekeuze; voor een gereedschap dat referenties verwerkt, is het de enige eerlijke basis voor een beveiligingsclaim.
Je moet gereedschappen verifiëren die je referenties verwerken. De gereedschappen die verificatie weerstaan, zijn de degene om je zorgen over te maken.
Als je tevreden bent, ga dan naar de figmascope-app om je Figma-contextbundel te exporteren en gebruik hem met Claude Code of Cursor.