要使用任何第三方 Figma 工具，你需要在 Figma 设置中生成个人访问令牌（PAT）并粘贴到工具中。这是基本要求。每个 Figma 集成都会要求它。

大多数人没有完全意识到的是：该令牌读取的不是"一个文件"。它读取你账户能访问的每个文件。每个私有文件。每个组织库。每个共享项目。Figma PAT 的默认权限范围是你整个账户的读取面。

对于拥有个人账户的个人设计师，这是适度的风险。对于企业员工设计师，其共享设计库包含未发布的产品、品牌资产和内部工具——风险就很大了。对这些设计师来说，"我把我的 Figma 令牌粘贴到了我找到的这个工具里"是一个安全事件。

figmascope 的设计使这种事件不会发生。

Figma PAT 授予什么权限

Figma 的 API 认证基于 PAT。令牌以你的身份进行认证。API 在令牌级别不强制执行每个文件的权限范围——它根据你账户的权限强制执行文件访问。如果你的账户可以查看某个文件，PAT 就可以通过 API 读取它。

默认 PAT 权限范围授予以下读取访问：

Figma 在 2023 年引入了更细粒度的令牌类型——你可以选择授予哪些权限范围的令牌。但 UI 默认为广泛令牌，大多数教程告诉你在不指定权限范围的情况下生成令牌。实际上，漂浮在设计师剪贴板历史记录中的大多数 PAT 都是完全读取令牌。

PAT 接受工具的威胁模型

接受 Figma PAT 并有后端的工具面临一个特定威胁：后端存储你的令牌（以代表你调用 Figma），而那个存储是一个攻击目标。如果后端被攻破，存储在那里的每个 PAT 都会被攻破。如果后端发生数据库泄露，每个用户的 Figma 访问权限都会被泄露。

这不是假设。OAuth 令牌存储泄露已经发生在许多服务上。模式是：用户授予访问权限，服务存储令牌，服务被攻破，攻击者泄露令牌，攻击者现在可以访问那些令牌能到达的一切。对于企业中的 Figma 令牌，"那些令牌能到达的一切"就是完整的设计系统。

基于后端的工具必须解决这个问题。好的工具会这样做：静态加密、短期令牌、重新认证工作流、审计日志。正确解决它是企业级安全工程问题。大多数工具没有正确解决它；它们只是还没有被攻破。

最安全的令牌存储是根本不存储。如果你的架构从不持久化令牌，就没有什么可以被攻破的。这是 figmascope 做出的架构选择——这不仅仅是一个功能，它是整个安全模型。

figmascope 的架构

figmascope 完全在浏览器中运行。没有后端服务器。没有数据库。没有会话管理、用户账户、令牌存储层。应用程序是从 CDN 提供的静态 HTML/CSS/JS 包。当你使用它时，计算在你的浏览器标签页中发生。没有任何东西被发送到 figmascope 服务器，因为根本没有 figmascope 服务器。

PAT 流程如下：

  1. 你在输入字段中输入 PAT。
  2. 该值存储在 JavaScript 闭包变量中——应用模块内的普通 JS let 绑定。
  3. 它从不写入 localStorage。从不写入 sessionStorage。从不设置为 cookie。从不写入 indexedDB。从不发送到两个 Figma API 端点以外的任何 URL。
  4. 当你进行导出时，令牌作为 X-Figma-Token 标头在对 api.figma.com 和 Figma CDN（用于图片资源）的 fetch() 调用中传递。
  5. 当你关闭或重新加载标签页时，JS 内存被释放。令牌消失了。

这是完整的生命周期。在任何地方都没有持久化。除了直接到 Figma 之外没有网络传输。

内容安全策略强制执行

为了使"仅发送到 Figma"的属性可强制执行而不仅仅是断言，figmascope 部署了内容安全策略（CSP），将 connect-src 锁定到两个允许的主机：

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

CSP 由浏览器强制执行。即使页面中存在脚本注入漏洞，浏览器也会阻止任何向第三方主机发送令牌的尝试。到任何其他目标的网络请求在浏览器级别失败，在它们离开机器之前就被阻止。

这是深度防御。应用代码已经不会将令牌发送到其他任何地方。CSP 使得即使应用代码试图这样做，它也无法将令牌发送到其他任何地方。

恢复路径

因为令牌仅在内存中，恢复很简单：关闭标签页。令牌消失了。不需要撤销步骤，不需要"删除账户"，不需要"退出登录"。标签页关闭 = 令牌消失。

从操作安全的角度来看，这也是正确的行为。短期的凭证窗口最小化暴露。你打开 figmascope，粘贴你的 PAT，进行导出，关闭标签页。PAT 可访问的窗口正好是那个浏览器会话的持续时间。与后端工具相比，那里你的令牌可能存储数月，处于活跃和可访问状态，直到你明确撤销它。

无论使用何种工具的建议

即使有 figmascope 的内存架构，良好的 PAT 安全习惯也很重要：

使用范围限定的令牌。Figma 现在支持具有明确范围的令牌。对于像 figmascope 导出这样的只读操作，只读令牌就足够了，并在令牌被暴露时限制了影响范围。生成只有 file_read 权限范围的令牌，而不是默认的广泛范围。

撤销你不积极使用的令牌。Figma 的设置显示所有活跃 PAT。你为已结束项目生成的令牌应该被撤销。你六个月前为 figmascope 生成且此后未使用的令牌可以撤销，下次需要时再重新生成。

除非你验证了其安全状况，否则不要将令牌粘贴到有后端的工具中。问：这个服务有后端吗？如果有，它在哪里以及如何存储我的令牌？如果答案不令人满意，或者没有答案，就将其视为风险。这适用于每个 Figma 工具，不仅仅是 figmascope。

企业用户：在可用的情况下使用共享/服务账户。如果你的组织可以创建一个对特定项目有只读访问权限的 Figma 服务账户，从该账户生成 PAT 而非从你的个人账户生成，可以将可访问范围限制在那些项目中。

我们不声称什么

figmascope 的仅浏览器架构最小化了服务器端凭证盗窃的攻击面。它并不消除所有安全顾虑：

我们并不声称这是企业级安全审计的替代品。我们声称的是：该架构使特定类别的攻击——服务器端令牌数据库泄露——通过消除服务器在结构上变得不可能。这是对攻击面有意义的减少，而不是完全免疫。

为什么开源在这里很重要

安全声明如果没有可验证性就毫无价值。figmascope 是 MIT 许可的，完整源代码在 GitHub 上。本文中的声明——没有 localStorage 写入、没有后端传输、CSP 标头——都可以通过阅读代码来验证。app.js 显示没有对浏览器存储 API 的写入。headers 文件显示 CSP。fetch 调用准确显示哪些 URL 接收令牌。

如果我们在这些方面撒谎，三十分钟就能找到谎言。这就是重点。开源不仅仅是许可证选择；对于处理凭证的工具，它是安全声明的唯一诚实基础。

你应该验证处理你凭证的工具。抵制验证的工具才是值得担心的。

一旦你满意了，前往 figmascope 应用导出你的 Figma 上下文包，并与 Claude Code 或 Cursor 一起使用。