Bezpieczeństwo PAT w narzędziach przeglądarkowych — Jak figmascope chroni Twój token Figma

Aby używać dowolnego narzędzia Figma strony trzeciej, generujesz Personal Access Token w ustawieniach Figmy i wklejasz go do narzędzia. To standard. Każda integracja Figmy o to prosi.

Czego większość ludzi w pełni nie rejestruje: ten token nie czyta "jednego pliku". Czyta każdy plik, do którego ma dostęp Twoje konto. Każdy prywatny plik. Każdą bibliotekę organizacyjną. Każdy udostępniony projekt. Domyślny zakres PAT Figmy to cała powierzchnia odczytu Twojego konta.

Dla indywidualnego projektanta z kontem osobistym to umiarkowane ryzyko. Dla etatowego projektanta w przedsiębiorstwie z udostępnionymi bibliotekami projektu zawierającymi nieopublikowane produkty, zasoby marki i wewnętrzne narzędzia — jest znaczące. I dla tych projektantów "wkleiłem mój token Figma do tego narzędzia, które znalazłem" to zdarzenie bezpieczeństwa.

figmascope jest zaprojektowany tak, by to zdarzenie nie miało miejsca.

Co daje PAT Figmy

Uwierzytelnianie API Figmy jest oparte na PAT. Token uwierzytelnia się jako Ty. API nie wymusza zakresu per-plik na poziomie tokenu — wymusza dostęp do pliku na podstawie uprawnień Twojego konta. Jeśli Twoje konto może wyświetlić plik, PAT może go odczytać przez API.

Domyślny zakres PAT daje dostęp do odczytu:

Wszystkich plików, które stworzyłeś
Wszystkich plików udostępnionych Ci
Wszystkich plików w projektach i zespołach, których jesteś członkiem
Opublikowanych bibliotek komponentów używanych przez Twój zespół

Figma wprowadziła bardziej ograniczony typ tokenu w 2023 roku — tokeny, w których możesz wybrać, które zakresy przyznać. Ale UI domyślnie wybiera szeroki token i większość samouczków mówi, by generować token bez określania zakresu. W praktyce większość PAT krążących w historii schowka projektantów to tokeny pełnego odczytu.

Model zagrożeń dla narzędzi akceptujących PAT

Narzędzie, które akceptuje PAT Figmy i ma backend, stoi przed konkretnym zagrożeniem: backend przechowuje token (by wywoływać Figmę w Twoim imieniu), a to przechowywanie jest celem. Jeśli backend zostanie naruszony, każdy przechowywany tam PAT jest naruszony. Jeśli backend ma wyciek bazy danych, dostęp do Figmy każdego użytkownika jest naruszony.

To nie jest hipotetyczne. Naruszenia przechowywania tokenów OAuth przytrafiły się wielu serwissom. Wzorzec jest: użytkownik udziela dostępu, serwis przechowuje token, serwis jest naruszany, atakujący eksfiltruje tokeny, atakujący ma teraz dostęp do wszystkiego, co te tokeny mogą osiągnąć. Dla tokenów Figma w przedsiębiorstwie "wszystko, co te tokeny mogą osiągnąć" to pełny system projektowania.

Narzędzia z backendem muszą rozwiązać ten problem. Dobre to robią: szyfrowanie danych w spoczynku, krótkotrwałe tokeny, workflow ponownego uwierzytelniania, logowanie audytowe. Właściwe rozwiązanie to problem inżynierii bezpieczeństwa klasy enterprise. Większość narzędzi nie rozwiązuje go właściwie; po prostu nie zostały jeszcze naruszone.

Najbezpieczniejsze przechowywanie tokenów to brak przechowywania w ogóle. Jeśli Twoja architektura nigdy nie persystuje tokenu, nie ma czego naruszyć. To wybór architektoniczny, który figmascope robi — i to nie jest tylko funkcja, to cały model bezpieczeństwa.

Architektura figmascope

figmascope działa całkowicie w przeglądarce. Nie ma serwera backend. Nie ma bazy danych. Nie ma zarządzania sesją, kont użytkowników, warstwy przechowywania tokenów. Aplikacja to statyczny pakiet HTML/CSS/JS serwowany z CDN. Gdy jej używasz, obliczenia odbywają się w zakładce przeglądarki. Nic nie jest wysyłane na serwery figmascope, bo nie ma serwerów figmascope.

Przepływ PAT wygląda następująco:

Wpisujesz PAT w pole wejściowe.
Wartość jest przechowywana w zmiennej zamknięcia JavaScript — zwykłym powiązaniu let JS wewnątrz modułu aplikacji.
Nigdy nie jest zapisywana do localStorage. Nigdy do sessionStorage. Nigdy ustawiana jako cookie. Nigdy zapisywana do indexedDB. Nigdy wysyłana na żaden URL inny niż dwa endpointy API Figmy.
Gdy robisz eksport, token jest przekazywany jako nagłówek X-Figma-Token w wywołaniach fetch() do api.figma.com i CDN Figmy dla assetów obrazów.
Gdy zamkniesz lub przeładujesz zakładkę, pamięć JS jest zwalniana. Token znika.

To kompletny cykl życia. Bez persystencji gdziekolwiek. Bez transmisji sieciowej poza bezpośrednio do Figmy.

Egzekwowanie Content Security Policy

Aby właściwość "wysyłany tylko do Figmy" była egzekwowalna, a nie tylko deklarowana, figmascope wdraża Content Security Policy, która blokuje connect-src do dwóch dozwolonych hostów:

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

CSP jest egzekwowany przez przeglądarkę. Nawet gdyby w stronie była luka wstrzyknięcia skryptu, przeglądarka blokowałaby każdą próbę wysłania tokenu do hosta strony trzeciej. Żądania sieciowe do dowolnego innego celu kończą się niepowodzeniem na poziomie przeglądarki, przed opuszczeniem maszyny.

To obrona wgłębna. Kod aplikacji już nie wysyła tokenu nigdzie indziej. CSP sprawia, że kod aplikacji nie może go wysłać nigdzie indziej, nawet gdyby próbował.

Ścieżka odzyskania

Ponieważ token jest tylko w pamięci, odzyskanie jest trywialne: zamknij zakładkę. Token zniknął. Żadnego kroku unieważnienia, żadnego "usuń konto", żadnego "wyloguj się". Zakładka zamknięta = token zniknął.

To również właściwe zachowanie z perspektywy bezpieczeństwa operacyjnego. Krótkie okna poświadczeń minimalizują ekspozycję. Otwierasz figmascope, wklejasz PAT, robisz eksporty, zamykasz zakładkę. Okno, w którym PAT jest dostępny, to dokładnie czas trwania tej sesji przeglądarki. Porównaj to z narzędziem backendowym, gdzie token może być przechowywany przez miesiące, aktywny i dostępny, dopóki explicite go nie unieważnisz.

Zalecenia niezależnie od narzędzia

Nawet przy architekturze in-memory figmascope, dobra higiena PAT ma znaczenie:

Używaj tokenu o ograniczonym zakresie. Figma teraz obsługuje tokeny z explicite zakresami. Dla operacji tylko do odczytu, jak eksporty figmascope, token tylko do odczytu jest wystarczający i ogranicza zasięg wybuchu, jeśli kiedykolwiek zostanie ujawniony. Generuj token z zakresem file_read tylko, nie domyślnym szerokim zakresem.

Unieważniaj tokeny, których aktywnie nie używasz. Ustawienia Figmy pokazują wszystkie aktywne PAT. Tokeny wygenerowane dla zakończonego projektu powinny być unieważnione. Token wygenerowany dla figmascope sześć miesięcy temu i nieużywany od tamtej pory może być unieważniony i zregenerowany następnym razem, gdy będziesz go potrzebować.

Nigdy nie wklejaj tokenów do narzędzi z backendem, dopóki nie zweryfikujesz ich podejścia do bezpieczeństwa. Zapytaj: czy ten serwis ma backend? Jeśli tak, gdzie i jak przechowuje mój token? Jeśli odpowiedź nie jest satysfakcjonująca lub jeśli nie ma odpowiedzi, traktuj to jako ryzyko. Dotyczy to każdego narzędzia Figma, nie tylko figmascope.

Użytkownicy enterprise: używaj współdzielonych/serwisowych kont, gdy to możliwe. Jeśli Twoja organizacja może tworzyć konta serwisowe Figmy z dostępem tylko do odczytu do konkretnych projektów, generowanie PAT z tego konta zamiast Twojego konta osobistego ogranicza dostępność do tych projektów.

Czego nie twierdzimy

Architektura tylko-przeglądarkowa figmascope minimalizuje powierzchnię ataku dla kradzieży poświadczeń po stronie serwera. Nie eliminuje wszystkich problemów bezpieczeństwa:

Rozszerzenia przeglądarki z szerokimi uprawnieniami mogą czytać zmienne JavaScript. Jeśli masz niezaufane rozszerzenia przeglądarki, stanowią ryzyko dla każdego poświadczenia, które wpiszesz do jakiejkolwiek aplikacji webowej.
Skompromitowana przeglądarka (złośliwe oprogramowanie, XSS na innej stronie, który wymyka się izolacji) potencjalnie mogłaby czytać pamięć w zakładce, choć nowoczesny sandbox przeglądarki bardzo utrudnia dostęp cross-origin.
Udostępnianie ekranu i podglądanie przez ramię są poza zakresem jakiejkolwiek architektury.

Nie twierdzimy, że to substytut audytu bezpieczeństwa klasy enterprise. Twierdzimy: architektura sprawia, że konkretna klasa ataku — naruszenie bazy danych tokenów po stronie serwera — jest strukturalnie niemożliwa przez eliminację serwera. To znaczna redukcja powierzchni ataku, nie pełna odporność.

Dlaczego open source ma tu znaczenie

Twierdzenia bezpieczeństwa są bez wartości bez możliwości weryfikacji. figmascope jest licencjonowany MIT i pełne źródło jest na GitHub. Twierdzenia w tym artykule — brak zapisów localStorage, brak transmisji do backendu, nagłówki CSP — wszystkie są weryfikowalne przez przeczytanie kodu. app.js nie pokazuje zapisów do API przechowywania przeglądarki. Plik nagłówków pokazuje CSP. Wywołania fetch pokazują dokładnie, które URL otrzymują token.

Gdybyśmy kłamali w tym zakresie, znalezienie kłamstwa zajęłoby trzydzieści minut. O to chodzi. Open source to nie tylko wybór licencji; dla narzędzia obsługującego poświadczenia to jedyna uczciwa podstawa dla twierdzenia bezpieczeństwa.

Powinieneś weryfikować narzędzia obsługujące Twoje poświadczenia. Narzędzia, które opierają się weryfikacji, są tymi wartymi niepokoju.

Gdy będziesz usatysfakcjonowany, przejdź do aplikacji figmascope, by wyeksportować pakiet kontekstowy Figmy i użyć go z Claude Code lub Cursor.