To use any third-party Figma tool, you generate a Personal Access Token in Figma's settings and paste it into the tool. This is table stakes. Every Figma integration asks for it.

What most people don't fully register: that token doesn't read "one file." It reads every file your account can access. Every private file. Every organizational library. Every shared project. The default scope of a Figma PAT is your entire account's read surface.

For an individual designer with a personal account, that's a moderate risk. For a staff designer at an enterprise with shared design libraries containing unreleased products, brand assets, and internal tooling — it's significant. And for those designers, "I pasted my Figma token into this tool I found" is a security event.

figmascope is designed so that event doesn't happen.

What a Figma PAT grants

Figma's API authentication is PAT-based. A token authenticates as you. The API doesn't enforce per-file scoping at the token level — it enforces file access based on your account's permissions. If your account can view a file, the PAT can read it via the API.

The default PAT scope grants read access to:

Figma introduced a more scoped token type in 2023 — tokens where you can select which scopes to grant. But the UI defaults to the broad token, and most tutorials tell you to generate a token without specifying scope. In practice, most PATs floating around in designers' clipboard history are full-read tokens.

The threat model for PAT-accepting tools

A tool that accepts a Figma PAT and has a backend faces a specific threat: the backend stores your token (to call Figma on your behalf), and that storage is a target. If the backend is compromised, every PAT stored there is compromised. If the backend has a database breach, every user's Figma access is breached.

This isn't hypothetical. OAuth token storage breaches have happened to many services. The pattern is: user grants access, service stores token, service is breached, attacker exfiltrates tokens, attacker now has access to everything those tokens can reach. For Figma tokens at an enterprise, "everything those tokens can reach" is the full design system.

Backend-based tools have to solve this problem. The good ones do: encryption at rest, short-lived tokens, re-auth workflows, audit logging. Solving it properly is an enterprise-grade security engineering problem. Most tools don't solve it properly; they just haven't been breached yet.

The most secure token storage is no storage at all. If your architecture never persists the token, there's nothing to breach. This is the architectural choice figmascope makes — and it's not just a feature, it's the entire security model.

figmascope's architecture

figmascope runs entirely in the browser. There is no backend server. There is no database. There is no session management, no user accounts, no token storage layer. The application is a static HTML/CSS/JS bundle served from a CDN. When you use it, computation happens in your browser tab. Nothing is sent to figmascope servers because there are no figmascope servers.

The PAT flow works as follows:

  1. You enter your PAT in the input field.
  2. The value is stored in a JavaScript closure variable — a regular JS let binding inside the application module.
  3. It is never written to localStorage. Never written to sessionStorage. Never set as a cookie. Never written to indexedDB. Never sent to any URL other than the two Figma API endpoints.
  4. When you make an export, the token is passed as the X-Figma-Token header in fetch() calls to api.figma.com and the Figma CDN for image assets.
  5. When you close or reload the tab, the JS memory is released. The token is gone.

This is the complete lifecycle. No persistence anywhere. No network transmission except directly to Figma.

Content Security Policy enforcement

To make the "only sent to Figma" property enforceable rather than just asserted, figmascope deploys a Content Security Policy that locks connect-src to the two permitted hosts:

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

CSP is browser-enforced. Even if there were a script injection vulnerability in the page, the browser would block any attempt to send the token to a third-party host. Network requests to any other destination fail at the browser level, before they leave the machine.

This is defense in depth. The application code already doesn't send the token anywhere else. The CSP makes it so application code can't send it anywhere else even if it tried.

Recovery path

Because the token is in-memory only, recovery is trivial: close the tab. The token is gone. No revocation step, no "delete account," no "sign out." Tab closed = token gone.

This is also the right behavior from an operational security perspective. Short-lived credential windows minimize exposure. You open figmascope, paste your PAT, do your exports, close the tab. The window in which the PAT is accessible is exactly the duration of that browser session. Contrast this with a backend tool where your token may be stored for months, active and accessible, until you explicitly revoke it.

Recommendations regardless of tool

Even with figmascope's in-memory architecture, good PAT hygiene matters:

Use a scoped token. Figma now supports tokens with explicit scopes. For read-only operations like figmascope exports, a read-only token is sufficient and limits blast radius if it's ever exposed. Generate a token with file_read scope only, not the default broad scope.

Revoke tokens you don't actively use. Figma's settings show all active PATs. Tokens you generated for a project that ended should be revoked. A token you generated for figmascope six months ago and haven't used since can be revoked and regenerated next time you need it.

Never paste tokens into tools with backends unless you've verified their security posture. Ask: does this service have a backend? If yes, where and how does it store my token? If the answer isn't satisfying, or if there's no answer, treat it as a risk. This applies to every Figma tool, not just figmascope.

Enterprise users: use shared/service accounts where available. If your organization can create a Figma service account with read-only access to specific projects, generating PATs from that account rather than your personal account limits what's accessible to those projects.

What we don't claim

figmascope's browser-only architecture minimizes the attack surface for server-side credential theft. It does not eliminate all security concerns:

We're not claiming this is a substitute for enterprise-grade security auditing. We're claiming: the architecture makes a specific class of attack — server-side token database breach — structurally impossible by eliminating the server. That's a meaningful reduction in attack surface, not complete immunity.

Why open source matters here

Security claims are worthless without verifiability. figmascope is MIT-licensed and the full source is on GitHub. The claims in this post — no localStorage writes, no backend transmission, CSP headers — are all verifiable by reading the code. The app.js shows no writes to browser storage APIs. The headers file shows the CSP. The fetch calls show exactly which URLs receive the token.

If we were lying about any of this, it would take thirty minutes to find the lie. That's the point. Open source isn't just a license choice; for a tool that handles credentials, it's the only honest basis for a security claim.

You should verify tools that handle your credentials. The tools that resist verification are the ones worth worrying about.

Once you're satisfied, head to the figmascope app to export your Figma context bundle and use it with Claude Code or Cursor.