Chcete-li používat jakýkoli nástroj Figmy třetí strany, vygenerujete Personal Access Token v nastavení Figmy a vložíte ho do nástroje. To je základní podmínka. Každá integrace Figmy o to žádá.

Co si většina lidí plně neuvědomuje: tento token nečte „jeden soubor." Čte každý soubor, ke kterému má váš účet přístup. Každý soukromý soubor. Každou organizační knihovnu. Každý sdílený projekt. Výchozí rozsah Figma PAT je celý povrch čtení vašeho účtu.

Pro individuálního designéra s osobním účtem je to střední riziko. Pro zaměstnance designéra ve firmě se sdílenými designovými knihovnami obsahujícími nevydané produkty, brandové materiály a interní nástroje — je to značné. A pro takové designéry „vložil jsem svůj token Figmy do tohoto nástroje, který jsem našel" je bezpečnostní událost.

figmascope je navržen tak, aby k této události nedošlo.

Co Figma PAT uděluje

Autentizace Figma API je založena na PAT. Token se autentizuje jako vy. API nevynucuje rozsah pro jednotlivé soubory na úrovni tokenu — vynucuje přístup k souborům na základě oprávnění vašeho účtu. Pokud váš účet může zobrazit soubor, PAT ho může číst prostřednictvím API.

Výchozí rozsah PAT uděluje přístup pro čtení k:

Figma v roce 2023 zavedla více rozsahovaný typ tokenu — tokeny, kde můžete vybrat, které rozsahy udělit. Ale UI je výchozí na širokém tokenu a většina návodů vám říká, abyste vygenerovali token bez specifikování rozsahu. V praxi je většina PAT pohybujících se v historii schránky designérů tokeny s plným čtením.

Model hrozeb pro nástroje přijímající PAT

Nástroj, který přijímá Figma PAT a má backend, čelí specifické hrozbě: backend ukládá váš token (aby mohl volat Figmu vaším jménem) a toto úložiště je cílem. Pokud je backend kompromitován, každý PAT tam uložený je kompromitován. Pokud dojde k úniku dat z databáze backendu, přístup k Figmě každého uživatele je prozrazen.

To není hypotetické. Úniky úložiště OAuth tokenů se staly mnoha službám. Vzor je: uživatel udělí přístup, služba uloží token, služba je narušena, útočník exfiltruje tokeny, útočník nyní má přístup ke všemu, čeho tyto tokeny mohou dosáhnout. U tokenů Figmy ve firmě „vše, čeho tyto tokeny mohou dosáhnout" je celý designový systém.

Nástroje na bázi backendu musí tento problém řešit. Ty dobré to dělají: šifrování v klidu, krátkodobé tokeny, pracovní postupy opětovné autentizace, protokolování auditů. Správné řešení je problém bezpečnostního inženýrství na podnikové úrovni. Většina nástrojů ho řeší nesprávně; jen ještě nebyly narušeny.

Nejbezpečnější úložiště tokenu je žádné úložiště. Pokud vaše architektura token nikdy neukládá, není co narušit. Toto je architektonická volba, kterou figmascope dělá — a není to jen funkce, je to celý bezpečnostní model.

Architektura figmascope

figmascope běží zcela v prohlížeči. Neexistuje žádný backendový server. Neexistuje žádná databáze. Neexistuje žádná správa relací, žádné uživatelské účty, žádná vrstva úložiště tokenů. Aplikace je statický balíček HTML/CSS/JS obsluhovaný z CDN. Když ho používáte, výpočty probíhají ve vaší záložce prohlížeče. Nic se neposílá na servery figmascope, protože žádné servery figmascope neexistují.

Tok PAT funguje takto:

  1. Zadáte svůj PAT do vstupního pole.
  2. Hodnota je uložena v proměnné JavaScript closure — běžné JS let vazby uvnitř modulu aplikace.
  3. Nikdy není zapsána do localStorage. Nikdy zapsána do sessionStorage. Nikdy nastavena jako cookie. Nikdy zapsána do indexedDB. Nikdy odeslána na žádnou URL jinou než na dva endpointy Figma API.
  4. Když provádíte export, token je předán jako záhlaví X-Figma-Token ve voláních fetch() na api.figma.com a CDN Figmy pro obrazová aktiva.
  5. Když zavřete nebo znovu načtete záložku, paměť JS je uvolněna. Token je pryč.

Toto je úplný životní cyklus. Žádné trvalé uložení nikde. Žádný síťový přenos kromě přímo na Figmu.

Vynucení Content Security Policy

Aby byla vlastnost „odesíláno pouze na Figmu" vynucovatelná, a nikoli pouze tvrzená, figmascope nasazuje Content Security Policy, která uzamkne connect-src na dva povolené hostitele:

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

CSP je vynucováno prohlížečem. I kdyby existovala zranitelnost skriptové injekce na stránce, prohlížeč by zablokoval jakýkoli pokus o odeslání tokenu na hostitele třetí strany. Síťové požadavky na jakýkoli jiný cíl selžou na úrovni prohlížeče, před opuštěním počítače.

Toto je hloubkové zabezpečení. Kód aplikace již token nikam jinam neposílá. CSP zajišťuje, že kód aplikace ho nikam jinam nemůže poslat, i kdyby se o to pokusil.

Cesta obnovy

Protože je token pouze v paměti, obnova je triviální: zavřete záložku. Token je pryč. Žádný krok odvolání, žádné „smazat účet," žádné „odhlásit se." Záložka zavřena = token pryč.

Toto je také správné chování z pohledu provozní bezpečnosti. Krátkodobá okna přihlašovacích údajů minimalizují expozici. Otevřete figmascope, vložíte svůj PAT, provedete exporty, zavřete záložku. Okno, ve kterém je PAT přístupný, je přesně délka té relace prohlížeče. Porovnejte to s backendovým nástrojem, kde může být váš token uložen měsíce, aktivní a přístupný, dokud ho explicitně neodvoláte.

Doporučení bez ohledu na nástroj

I s architekturou figmascope pouze v paměti záleží na dobré hygieně PAT:

Použijte rozsahovaný token. Figma nyní podporuje tokeny s explicitními rozsahy. Pro operace pouze pro čtení, jako jsou exporty figmascope, je dostatečný token pouze pro čtení a omezuje dopad v případě, že je někdy odhalen. Vygenerujte token pouze s rozsahem file_read, nikoli výchozím širokým rozsahem.

Odvolejte tokeny, které aktivně nepoužíváte. Nastavení Figmy zobrazuje všechny aktivní PAT. Tokeny, které jste vygenerovali pro projekt, který skončil, by měly být odvolány. Token, který jste vygenerovali pro figmascope před šesti měsíci a od té doby nepoužili, může být odvolán a příště, kdy ho budete potřebovat, znovu vygenerován.

Nikdy nevkládejte tokeny do nástrojů s backendy, pokud jste neověřili jejich bezpečnostní postoj. Zeptejte se: má tato služba backend? Pokud ano, kde a jak ukládá můj token? Pokud odpověď není uspokojivá nebo pokud žádná odpověď neexistuje, považujte to za riziko. To platí pro každý nástroj Figmy, nejen figmascope.

Podnikoví uživatelé: kde je to možné, používejte sdílené/servisní účty. Pokud vaše organizace může vytvořit servisní účet Figmy s přístupem pouze pro čtení ke konkrétním projektům, generování PAT z tohoto účtu namísto vašeho osobního účtu omezuje přístupný obsah na tyto projekty.

Co netvrdíme

Architektura figmascope pouze v prohlížeči minimalizuje povrch útoku pro krádež přihlašovacích údajů na straně serveru. Neeliminuje všechny bezpečnostní obavy:

Netvrdíme, že jde o náhradu auditování bezpečnosti na podnikové úrovni. Tvrdíme: architektura znemožňuje konkrétní třídu útoku — narušení databáze tokenů na straně serveru — strukturálně eliminací serveru. To je smysluplné snížení povrchu útoku, nikoli úplná imunita.

Proč zde záleží na open source

Bezpečnostní tvrzení jsou bezcenná bez ověřitelnosti. figmascope je licencován pod MIT a úplný zdrojový kód je na GitHubu. Tvrzení v tomto příspěvku — žádné zápisy do localStorage, žádný přenos backendu, CSP záhlaví — jsou všechna ověřitelná čtením kódu. app.js neukazuje žádné zápisy do API úložiště prohlížeče. Soubor záhlaví ukazuje CSP. Volání fetch ukazují přesně, které URL dostávají token.

Kdybychom lhali o čemkoli z toho, trvalo by třicet minut najít lež. To je smysl. Open source není jen licenční volba; pro nástroj, který zpracovává přihlašovací údaje, je to jediný čestný základ pro bezpečnostní tvrzení.

Měli byste ověřovat nástroje, které zpracovávají vaše přihlašovací údaje. Nástroje, které se ověření brání, jsou ty, o které se vyplatí starat.

Jakmile budete spokojeni, přejděte do aplikace figmascope a exportujte svůj kontextový balíček Figmy a použijte ho s Claude Code nebo Cursor.