För att använda ett tredjeparts Figma-verktyg genererar du en personlig åtkomsttoken i Figmas inställningar och klistrar in den i verktyget. Det är grundläggande. Varje Figma-integration ber om det.

Vad de flesta inte helt registrerar: den token läser inte "en fil." Den läser varje fil ditt konto kan komma åt. Varje privat fil. Varje organisationsbibliotek. Varje delat projekt. Standardomfånget för en Figma PAT är hela ditt kontos läsyta.

För en enskild designer med ett personligt konto är det en måttlig risk. För en företagsdesigner på ett företag med delade designbibliotek som innehåller opublicerade produkter, varumärkestillgångar och interna verktyg — är det betydande. Och för de designerna är "jag klistrade in min Figma-token i det här verktyget jag hittade" en säkerhetshändelse.

figmascope är designat så att den händelsen inte inträffar.

Vad en Figma PAT ger

Figmas API-autentisering är PAT-baserad. En token autentiserar som dig. API:et tillämpar inte per-fil-scoping på tokennivån — det tillämpar filåtkomst baserat på ditt kontos behörigheter. Om ditt konto kan visa en fil kan PAT:en läsa den via API:et.

Standard-PAT-omfånget ger läsåtkomst till:

Figma introducerade en mer begränsad tokentyp 2023 — tokens där du kan välja vilka omfång att ge. Men gränssnittet är standard till den breda token, och de flesta handledningar berättar att du ska generera en token utan att specificera omfång. I praktiken är de flesta PAT:er som flödar runt i designers urklippshistorik full-läs-tokens.

Hotmodellen för PAT-accepterande verktyg

Ett verktyg som accepterar en Figma PAT och har en backend möter ett specifikt hot: backend lagrar din token (för att anropa Figma på dina vägnar), och den lagringen är ett mål. Om backend komprometteras är varje PAT lagrad där komprometterad. Om backend råkar ut för ett databasintrång är varje användares Figma-åtkomst bruten.

Det här är inte hypotetiskt. OAuth-tokenlager-intrång har hänt många tjänster. Mönstret är: användare ger åtkomst, tjänst lagrar token, tjänst intrångas, angripare exfiltrerar tokens, angripare har nu åtkomst till allt de tokens kan nå. För Figma-tokens på ett företag är "allt de tokens kan nå" hela designsystemet.

Backend-baserade verktyg måste lösa det här problemet. De bra gör det: kryptering i vila, kortlivade tokens, omautentiseringsarbetsflöden, granskningsloggning. Att lösa det ordentligt är ett säkerhetstekniskt problem på företagsnivå. De flesta verktyg löser det inte ordentligt; de har bara inte intrångats än.

Den säkraste tokenlagringen är ingen lagring alls. Om din arkitektur aldrig persisterar token finns det inget att intrångas. Det här är det arkitektoniska valet figmascope gör — och det är inte bara en funktion, det är hela säkerhetsmodellen.

figmascopes arkitektur

figmascope körs helt i webbläsaren. Det finns ingen backend-server. Det finns ingen databas. Det finns ingen sessionshantering, inga användarkonton, inget tokenlagringslager. Applikationen är ett statiskt HTML/CSS/JS-paket serverat från ett CDN. När du använder det sker beräkning i din webbläsarflik. Ingenting skickas till figmascope-servrar för att det inte finns några figmascope-servrar.

PAT-flödet fungerar så här:

  1. Du anger din PAT i inmatningsfältet.
  2. Värdet lagras i en JavaScript-stängningsvariabel — en vanlig JS let-bindning inuti applikationsmodulen.
  3. Det skrivs aldrig till localStorage. Aldrig skrivet till sessionStorage. Aldrig satt som en cookie. Aldrig skrivet till indexedDB. Aldrig skickat till någon URL utom de två Figma API-slutpunkterna.
  4. När du gör en export skickas token som X-Figma-Token-headern i fetch()-anrop till api.figma.com och Figma CDN för bildtillgångar.
  5. När du stänger eller laddar om fliken frigörs JS-minnet. Token är borta.

Det här är den fullständiga livscykeln. Ingen persistens någonstans. Ingen nätverksöverföring förutom direkt till Figma.

Content Security Policy-verkställighet

För att göra egenskapen "skickas bara till Figma" verkningsbar snarare än bara påstådd driftsätter figmascope en Content Security Policy som låser connect-src till de två tillåtna värdarna:

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

CSP verkställs av webbläsaren. Även om det vore en skriptinjektionssårbarhet på sidan skulle webbläsaren blockera alla försök att skicka token till en tredjeparts värd. Nätverksbegäranden till någon annan destination misslyckas på webbläsarnivå, innan de lämnar maskinen.

Det här är försvar på djupet. Applikationskoden skickar redan inte token någon annanstans. CSP gör det så att applikationskod inte kan skicka den någon annanstans ens om den försökte.

Återhämtningsväg

Eftersom token bara finns i minnet är återhämtning trivial: stäng fliken. Token är borta. Inget återkallningssteg, inget "radera konto," inget "logga ut." Flik stängd = token borta.

Det här är också rätt beteende ur ett operativt säkerhetsperspektiv. Kortlivade autentiseringsfönster minimerar exponering. Du öppnar figmascope, klistrar in din PAT, gör dina exporter, stänger fliken. Fönstret där PAT:en är tillgänglig är exakt varaktigheten av den webbläsarsessionen. Jämför det med ett backend-verktyg där din token kan lagras i månader, aktiv och tillgänglig, tills du explicit återkallar den.

Rekommendationer oavsett verktyg

Även med figmascopes in-memory-arkitektur spelar god PAT-hygien roll:

Använd en begränsad token. Figma stöder nu tokens med explicita omfång. För skrivskyddade operationer som figmascope-exporter är en skrivskyddad token tillräcklig och begränsar explosionsradien om den någonsin exponeras. Generera en token med enbart file_read-omfång, inte det breda standardomfånget.

Återkalla tokens du inte aktivt använder. Figmas inställningar visar alla aktiva PAT:er. Tokens du genererade för ett projekt som avslutades bör återkallas. En token du genererade för figmascope för sex månader sedan och inte använt sedan kan återkallas och regenereras nästa gång du behöver det.

Klistra aldrig in tokens i verktyg med backends om du inte verifierat deras säkerhetsprofil. Fråga: har den här tjänsten en backend? Om ja, var och hur lagrar den min token? Om svaret inte är tillfredsställande, eller om det inte finns något svar, behandla det som en risk. Det gäller varje Figma-verktyg, inte bara figmascope.

Företagsanvändare: använd delade/tjänstekonton där det är tillgängligt. Om din organisation kan skapa ett Figma-tjänstekonto med skrivskyddad åtkomst till specifika projekt begränsar generering av PAT:er från det kontot snarare än ditt personliga konto vad som är tillgängligt till de projekten.

Vad vi inte påstår

figmascopes webbläsarbaserade arkitektur minimerar attackytan för serversidans autentiseringsstöld. Den eliminerar inte alla säkerhetsbekymmer:

Vi påstår inte att det här är ett substitut för säkerhetsgranskning på företagsnivå. Vi påstår: arkitekturen gör en specifik klass av attacker — intrång i serversidans tokendatabas — strukturellt omöjliga genom att eliminera servern. Det är en meningsfull minskning av attackyta, inte fullständig immunitet.

Varför open source spelar roll här

Säkerhetspåståenden är värdelösa utan verifierbarhet. figmascope är MIT-licensierat och den fullständiga källkoden finns på GitHub. Påståendena i det här inlägget — inga localStorage-skrivningar, ingen backend-överföring, CSP-headers — är alla verifierbara genom att läsa koden. app.js visar inga skrivningar till webbläsarlagrings-API:er. Headers-filen visar CSP:n. Fetch-anropen visar exakt vilka URL:er som tar emot token.

Om vi ljög om något av det här skulle det ta trettio minuter att hitta lögnen. Det är poängen. Open source är inte bara ett licensval; för ett verktyg som hanterar autentiseringsuppgifter är det den enda ärliga grunden för ett säkerhetspåstående.

Du bör verifiera verktyg som hanterar dina autentiseringsuppgifter. Verktygen som motverkar verifiering är de värda att oroa sig för.

När du är nöjd, gå till figmascope-appen för att exportera ditt Figma kontextpaket och använd det med Claude Code eller Cursor.