PAT-Sicherheit in Browser-basierten Tools — Wie figmascope Ihr Figma-Token schützt

Um ein Figma-Tool eines Drittanbieters zu verwenden, generiert man ein Personal Access Token in Figmas Einstellungen und fügt es in das Tool ein. Das ist Standard. Jede Figma-Integration fragt danach.

Was die meisten Menschen nicht vollständig registrieren: Dieses Token liest nicht "eine Datei". Es liest jede Datei, auf die das Konto zugreifen kann. Jede private Datei. Jede Organisationsbibliothek. Jedes geteilte Projekt. Der Standardbereich eines Figma-PAT ist die gesamte Lese-Oberfläche des Kontos.

Für einen einzelnen Designer mit einem persönlichen Konto ist das ein moderates Risiko. Für einen Staff-Designer bei einem Unternehmen mit geteilten Design-Bibliotheken, die unveröffentlichte Produkte, Marken-Assets und interne Tooling enthalten — ist es erheblich. Und für diese Designer ist "Ich habe mein Figma-Token in dieses Tool eingefügt, das ich gefunden habe" ein Sicherheitsereignis.

figmascope ist so designed, dass dieses Ereignis nicht eintritt.

Was ein Figma-PAT gewährt

Figmas API-Authentifizierung ist PAT-basiert. Ein Token authentifiziert sich als der Benutzer. Die API erzwingt kein datei-seitiges Scoping auf Token-Ebene — sie erzwingt Dateizugriff basierend auf den Berechtigungen des Kontos. Wenn das Konto eine Datei anzeigen kann, kann das PAT sie über die API lesen.

Der Standard-PAT-Bereich gewährt Lesezugriff auf:

• Alle selbst erstellten Dateien
• Alle geteilten Dateien
• Alle Dateien in Projekten und Teams, in denen man Mitglied ist
• Veröffentlichte Komponentenbibliotheken des Teams

Figma führte 2023 einen gezielteren Token-Typ ein — Tokens, bei denen man auswählen kann, welche Bereiche zu gewähren sind. Aber die Benutzeroberfläche standardisiert auf das breite Token, und die meisten Tutorials sagen einem, ein Token ohne Bereichsangabe zu generieren. In der Praxis sind die meisten PATs, die im Zwischenablageverlauf von Designern schweben, Full-Read-Tokens.

Das Bedrohungsmodell für PAT-akzeptierende Tools

Ein Tool, das ein Figma-PAT akzeptiert und ein Backend hat, sieht sich mit einer spezifischen Bedrohung konfrontiert: Das Backend speichert das Token (um Figma im Namen des Benutzers aufzurufen), und dieser Speicher ist ein Angriffsziel. Wenn das Backend kompromittiert wird, ist jedes dort gespeicherte PAT kompromittiert. Bei einem Datenbankbruch werden alle Figma-Zugänge der Benutzer gebrochen.

Das ist nicht hypothetisch. OAuth-Token-Speicher-Brüche sind bei vielen Diensten passiert. Das Muster ist: Benutzer gewährt Zugang, Dienst speichert Token, Dienst wird gebrochen, Angreifer exfiltriert Tokens, Angreifer hat jetzt Zugang zu allem, was diese Tokens erreichen können. Für Figma-Tokens in einem Unternehmen ist "alles, was diese Tokens erreichen können" das vollständige Design-System.

Backend-basierte Tools müssen dieses Problem lösen. Die guten lösen es: Verschlüsselung im Ruhezustand, kurzlebige Tokens, Re-Auth-Workflows, Audit-Logging. Es richtig zu lösen ist ein Enterprise-Grade-Sicherheitstechnik-Problem. Die meisten Tools lösen es nicht richtig; sie wurden einfach noch nicht gebrochen.

Die sicherste Token-Speicherung ist gar keine Speicherung. Wenn die Architektur das Token nie persistiert, gibt es nichts zu brechen. Das ist die architektonische Entscheidung, die figmascope trifft — und das ist nicht nur ein Feature, es ist das gesamte Sicherheitsmodell.

figmascopes Architektur

figmascope läuft vollständig im Browser. Es gibt keinen Backend-Server. Keine Datenbank. Kein Session-Management, keine Benutzerkonten, keine Token-Speicherschicht. Die Anwendung ist ein statisches HTML/CSS/JS-Bundle, das von einem CDN ausgeliefert wird. Bei der Verwendung findet die Berechnung im Browser-Tab statt. Nichts wird an figmascope-Server gesendet, weil es keine figmascope-Server gibt.

Der PAT-Fluss funktioniert wie folgt:

1. Man gibt das PAT in das Eingabefeld ein.
2. Der Wert wird in einer JavaScript-Closure-Variable gespeichert — einer regulären JS-let-Bindung innerhalb des Anwendungsmoduls.
3. Er wird nie in localStorage geschrieben. Nie in sessionStorage. Nie als Cookie gesetzt. Nie in indexedDB geschrieben. Nie an eine andere URL als die zwei Figma-API-Endpunkte gesendet.
4. Beim Export wird das Token als X-Figma-Token-Header in fetch()-Aufrufen an api.figma.com und das Figma-CDN für Bild-Assets übergeben.
5. Wenn der Tab geschlossen oder neu geladen wird, wird der JS-Speicher freigegeben. Das Token ist weg.

Das ist der vollständige Lebenszyklus. Keine Persistenz nirgendwo. Keine Netzwerkübertragung außer direkt zu Figma.

Content Security Policy Enforcement

Um die Eigenschaft "nur an Figma gesendet" durchsetzbar zu machen, anstatt sie nur zu behaupten, setzt figmascope eine Content Security Policy ein, die connect-src auf die zwei erlaubten Hosts beschränkt:

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

CSP wird vom Browser durchgesetzt. Selbst wenn es eine Script-Injection-Schwachstelle auf der Seite gäbe, würde der Browser jeden Versuch blockieren, das Token an einen Drittanbieter-Host zu senden. Netzwerkanfragen an jedes andere Ziel scheitern auf Browser-Ebene, bevor sie das Gerät verlassen.

Das ist Defense in Depth. Der Anwendungscode sendet das Token bereits nirgendwo anders hin. Die CSP macht es so, dass Anwendungscode es nicht anderswohin senden kann, selbst wenn er es versuchte.

Wiederherstellungspfad

Da das Token nur im Speicher ist, ist die Wiederherstellung trivial: Tab schließen. Das Token ist weg. Kein Widerrufschritt, kein "Konto löschen", kein "Abmelden". Tab geschlossen = Token weg.

Das ist auch das richtige Verhalten aus einer operativen Sicherheitsperspektive. Kurzlebige Credential-Fenster minimieren die Exposition. Man öffnet figmascope, fügt das PAT ein, macht Exporte, schließt den Tab. Das Fenster, in dem das PAT zugänglich ist, ist genau die Dauer dieser Browser-Session. Vergleich dazu ein Backend-Tool, bei dem das Token möglicherweise monatelang gespeichert, aktiv und zugänglich ist, bis man es explizit widerruft.

Empfehlungen unabhängig vom Tool

Selbst mit figmascopes In-Memory-Architektur ist gute PAT-Hygiene wichtig:

Einen gezielten Token verwenden. Figma unterstützt nun Tokens mit expliziten Bereichen. Für schreibgeschützte Operationen wie figmascope-Exporte ist ein schreibgeschütztes Token ausreichend und begrenzt den Explosionsradius, wenn es jemals exponiert wird. Einen Token mit nur file_read-Bereich generieren, nicht den Standard-Breitbereich.

Nicht aktiv genutzte Tokens widerrufen. Figmas Einstellungen zeigen alle aktiven PATs. Tokens, die für ein abgeschlossenes Projekt generiert wurden, sollten widerrufen werden. Ein Token, das vor sechs Monaten für figmascope generiert wurde und seitdem nicht verwendet wurde, kann widerrufen und beim nächsten Bedarf neu generiert werden.

Niemals Tokens in Tools mit Backends einfügen, ohne deren Sicherheitslage zu überprüfen. Fragen: Hat dieser Dienst ein Backend? Wenn ja, wo und wie speichert er mein Token? Wenn die Antwort nicht befriedigend ist oder wenn es keine Antwort gibt, als Risiko behandeln. Das gilt für jedes Figma-Tool, nicht nur figmascope.

Enterprise-Benutzer: geteilte/Service-Konten verwenden, wo verfügbar. Wenn die Organisation ein Figma-Service-Konto mit schreibgeschütztem Zugang zu bestimmten Projekten erstellen kann, begrenzt das Generieren von PATs aus diesem Konto statt dem persönlichen Konto, was zugänglich ist, auf diese Projekte.

Was wir nicht behaupten

figmascopes Nur-Browser-Architektur minimiert die Angriffsfläche für serverseitigen Credential-Diebstahl. Sie eliminiert nicht alle Sicherheitsbedenken:

• Browser-Erweiterungen mit breiten Berechtigungen können JavaScript-Variablen lesen. Wenn es nicht vertrauenswürdige Browser-Erweiterungen gibt, stellen sie ein Risiko für jedes Credential dar, das in eine Webanwendung eingegeben wird.
• Ein kompromittierter Browser (Malware, XSS auf einer anderen Seite, die aus der Isolation entkommt) könnte möglicherweise In-Tab-Speicher lesen, obwohl modernes Browser-Sandboxing Cross-Origin-Zugriff sehr schwierig macht.
• Screen-Sharing und Schulter-Surfen liegen außerhalb des Geltungsbereichs jeder Architektur.

Es wird nicht behauptet, dass das ein Ersatz für Enterprise-Grade-Sicherheitsauditing ist. Es wird behauptet: Die Architektur macht eine spezifische Klasse von Angriffen — serverseitiger Token-Datenbankbruch — strukturell unmöglich, indem der Server eliminiert wird. Das ist eine bedeutende Reduzierung der Angriffsfläche, keine vollständige Immunität.

Warum Open Source hier wichtig ist

Sicherheitsansprüche sind ohne Verifizierbarkeit wertlos. figmascope ist MIT-lizenziert und der vollständige Quellcode ist auf GitHub. Die Behauptungen in diesem Beitrag — keine localStorage-Schreibvorgänge, keine Backend-Übertragung, CSP-Header — sind alle durch Lesen des Codes verifizierbar. Die app.js zeigt keine Schreibvorgänge in Browser-Storage-APIs. Die Headers-Datei zeigt die CSP. Die fetch-Aufrufe zeigen genau, welche URLs das Token erhalten.

Wenn irgendetwas davon gelogen wäre, würde es dreißig Minuten dauern, die Lüge zu finden. Das ist der Punkt. Open Source ist nicht nur eine Lizenzwahl; für ein Tool, das Credentials behandelt, ist es die einzige ehrliche Grundlage für einen Sicherheitsanspruch.

Man sollte Tools verifizieren, die die eigenen Credentials handhaben. Die Tools, die sich der Verifizierung widersetzen, sind diejenigen, über die man sich Sorgen machen sollte.

Sobald man zufrieden ist, zur figmascope-App gehen, um das Figma-Kontext-Bundle zu exportieren und es mit Claude Code oder Cursor zu verwenden.