Để sử dụng bất kỳ công cụ Figma của bên thứ ba nào, bạn tạo Personal Access Token trong cài đặt Figma và dán vào công cụ. Đây là điều hiển nhiên. Mọi tích hợp Figma đều yêu cầu điều này.

Điều mà hầu hết mọi người không nhận ra đầy đủ: token đó không đọc "một file". Nó đọc mọi file tài khoản của bạn có thể truy cập. Mọi file riêng tư. Mọi thư viện tổ chức. Mọi dự án được chia sẻ. Phạm vi mặc định của PAT Figma là toàn bộ bề mặt đọc của tài khoản bạn.

Đối với một nhà thiết kế cá nhân có tài khoản cá nhân, đó là rủi ro vừa phải. Đối với nhà thiết kế nhân viên tại doanh nghiệp có thư viện thiết kế chung chứa sản phẩm chưa phát hành, tài sản thương hiệu và công cụ nội bộ — đó là rủi ro đáng kể. Và với những nhà thiết kế đó, "Tôi đã dán token Figma vào công cụ này mà tôi tìm thấy" là một sự cố bảo mật.

figmascope được thiết kế để sự cố đó không xảy ra.

PAT Figma cấp quyền gì

Xác thực API Figma dựa trên PAT. Token xác thực với tư cách là bạn. API không thực thi phạm vi theo từng file ở cấp độ token — nó thực thi quyền truy cập file dựa trên quyền của tài khoản bạn. Nếu tài khoản của bạn có thể xem một file, PAT có thể đọc nó qua API.

Phạm vi PAT mặc định cấp quyền đọc cho:

Figma đã giới thiệu loại token phạm vi hẹp hơn vào năm 2023 — các token nơi bạn có thể chọn phạm vi cấp phép. Nhưng giao diện mặc định là token rộng, và hầu hết các hướng dẫn đều bảo bạn tạo token mà không chỉ định phạm vi. Trên thực tế, hầu hết các PAT đang lưu trong lịch sử clipboard của nhà thiết kế đều là token đọc đầy đủ.

Mô hình mối đe dọa cho các công cụ chấp nhận PAT

Một công cụ chấp nhận PAT Figma và có backend đối mặt với mối đe dọa cụ thể: backend lưu trữ token của bạn (để gọi Figma thay mặt bạn), và việc lưu trữ đó là mục tiêu. Nếu backend bị xâm phạm, mọi PAT được lưu ở đó đều bị xâm phạm. Nếu backend có vi phạm cơ sở dữ liệu, quyền truy cập Figma của mọi người dùng đều bị vi phạm.

Điều này không phải giả thuyết. Vi phạm lưu trữ token OAuth đã xảy ra với nhiều dịch vụ. Mô hình là: người dùng cấp quyền truy cập, dịch vụ lưu trữ token, dịch vụ bị vi phạm, kẻ tấn công lọc token, kẻ tấn công hiện có quyền truy cập vào mọi thứ những token đó có thể tiếp cận. Đối với token Figma tại doanh nghiệp, "mọi thứ những token đó có thể tiếp cận" là toàn bộ hệ thống thiết kế.

Các công cụ dựa trên backend phải giải quyết vấn đề này. Những công cụ tốt làm được: mã hóa khi nghỉ, token ngắn hạn, quy trình tái xác thực, nhật ký kiểm tra. Giải quyết đúng cách là vấn đề kỹ thuật bảo mật cấp doanh nghiệp. Hầu hết các công cụ không giải quyết đúng cách; họ chỉ chưa bị vi phạm.

Cách lưu trữ token an toàn nhất là không lưu trữ gì cả. Nếu kiến trúc của bạn không bao giờ lưu trữ token, không có gì để vi phạm. Đây là lựa chọn kiến trúc mà figmascope thực hiện — và đó không chỉ là một tính năng, đó là toàn bộ mô hình bảo mật.

Kiến trúc của figmascope

figmascope chạy hoàn toàn trong trình duyệt. Không có máy chủ backend. Không có cơ sở dữ liệu. Không có quản lý phiên, không có tài khoản người dùng, không có lớp lưu trữ token. Ứng dụng là một bundle HTML/CSS/JS tĩnh được phục vụ từ CDN. Khi bạn sử dụng nó, tính toán xảy ra trong tab trình duyệt của bạn. Không có gì được gửi đến máy chủ figmascope vì không có máy chủ figmascope nào.

Luồng PAT hoạt động như sau:

  1. Bạn nhập PAT vào trường input.
  2. Giá trị được lưu trữ trong một biến closure JavaScript — một binding let thông thường bên trong module ứng dụng.
  3. Nó không bao giờ được ghi vào localStorage. Không bao giờ ghi vào sessionStorage. Không bao giờ được đặt làm cookie. Không bao giờ ghi vào indexedDB. Không bao giờ gửi đến bất kỳ URL nào ngoài hai endpoint Figma API.
  4. Khi bạn thực hiện xuất, token được truyền dưới dạng header X-Figma-Token trong các cuộc gọi fetch() đến api.figma.com và Figma CDN cho các tài nguyên ảnh.
  5. Khi bạn đóng hoặc tải lại tab, bộ nhớ JS được giải phóng. Token biến mất.

Đây là vòng đời đầy đủ. Không lưu trữ ở đâu cả. Không truyền mạng nào ngoài trực tiếp đến Figma.

Thực thi Content Security Policy

Để làm cho thuộc tính "chỉ gửi đến Figma" có thể thực thi được hơn là chỉ được khẳng định, figmascope triển khai Content Security Policy khóa connect-src cho hai host được phép:

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

CSP được thực thi bởi trình duyệt. Ngay cả khi có lỗ hổng chèn script trong trang, trình duyệt sẽ chặn mọi nỗ lực gửi token đến host bên thứ ba. Các yêu cầu mạng đến bất kỳ đích nào khác đều thất bại ở cấp độ trình duyệt, trước khi rời máy.

Đây là phòng thủ theo chiều sâu. Mã ứng dụng đã không gửi token đi đâu khác. CSP làm cho mã ứng dụng không thể gửi đi đâu khác ngay cả khi nó cố gắng.

Đường dẫn phục hồi

Vì token chỉ ở trong bộ nhớ, việc phục hồi rất đơn giản: đóng tab. Token biến mất. Không cần bước thu hồi, không cần "xóa tài khoản", không cần "đăng xuất". Đóng tab = token biến mất.

Đây cũng là hành vi đúng từ góc độ bảo mật vận hành. Cửa sổ thông tin xác thực ngắn hạn giảm thiểu rủi ro phơi lộ. Bạn mở figmascope, dán PAT, thực hiện xuất, đóng tab. Cửa sổ mà PAT có thể truy cập chính xác là thời gian của phiên trình duyệt đó. So sánh với công cụ backend nơi token của bạn có thể được lưu trữ trong nhiều tháng, hoạt động và có thể truy cập, cho đến khi bạn thu hồi rõ ràng.

Khuyến nghị bất kể công cụ nào

Ngay cả với kiến trúc bộ nhớ của figmascope, vệ sinh PAT tốt vẫn quan trọng:

Sử dụng token có phạm vi. Figma hiện hỗ trợ token với phạm vi rõ ràng. Đối với các thao tác chỉ đọc như xuất figmascope, token chỉ đọc là đủ và giới hạn bán kính nổ nếu nó bị phơi lộ. Tạo token chỉ với phạm vi file_read, không phải phạm vi mặc định rộng.

Thu hồi token bạn không sử dụng chủ động. Cài đặt Figma hiển thị tất cả PAT đang hoạt động. Token bạn đã tạo cho một dự án đã kết thúc nên được thu hồi. Token bạn đã tạo cho figmascope sáu tháng trước và chưa sử dụng kể từ đó có thể được thu hồi và tạo lại vào lần tới bạn cần.

Không bao giờ dán token vào các công cụ có backend trừ khi bạn đã xác minh vị thế bảo mật của chúng. Hỏi: dịch vụ này có backend không? Nếu có, nó lưu trữ token của tôi ở đâu và như thế nào? Nếu câu trả lời không thỏa đáng, hoặc nếu không có câu trả lời, hãy coi đó là rủi ro. Điều này áp dụng cho mọi công cụ Figma, không chỉ figmascope.

Người dùng doanh nghiệp: sử dụng tài khoản chung/dịch vụ khi có. Nếu tổ chức của bạn có thể tạo tài khoản dịch vụ Figma với quyền truy cập chỉ đọc cho các dự án cụ thể, việc tạo PAT từ tài khoản đó thay vì tài khoản cá nhân giới hạn những gì có thể truy cập cho các dự án đó.

Những gì chúng tôi không tuyên bố

Kiến trúc chỉ trình duyệt của figmascope giảm thiểu bề mặt tấn công cho việc đánh cắp thông tin xác thực phía máy chủ. Nó không loại bỏ tất cả các mối lo ngại bảo mật:

Chúng tôi không tuyên bố đây là sự thay thế cho kiểm toán bảo mật cấp doanh nghiệp. Chúng tôi tuyên bố: kiến trúc làm cho một lớp tấn công cụ thể — vi phạm cơ sở dữ liệu token phía máy chủ — không thể về mặt cấu trúc bằng cách loại bỏ máy chủ. Đó là sự giảm thiểu đáng kể bề mặt tấn công, không phải miễn nhiễm hoàn toàn.

Tại sao mã nguồn mở quan trọng ở đây

Các tuyên bố bảo mật vô giá trị nếu không thể xác minh. figmascope được cấp phép MIT và toàn bộ mã nguồn có trên GitHub. Các tuyên bố trong bài viết này — không ghi localStorage, không truyền backend, header CSP — đều có thể xác minh bằng cách đọc mã. app.js cho thấy không có ghi vào API lưu trữ trình duyệt. File header cho thấy CSP. Các cuộc gọi fetch cho thấy chính xác URL nào nhận token.

Nếu chúng tôi nói dối về bất kỳ điều nào trong số này, sẽ mất ba mươi phút để tìm ra lời nói dối. Đó là điểm mấu chốt. Mã nguồn mở không chỉ là lựa chọn giấy phép; đối với một công cụ xử lý thông tin xác thực, đó là cơ sở duy nhất trung thực cho một tuyên bố bảo mật.

Bạn nên xác minh các công cụ xử lý thông tin xác thực của bạn. Những công cụ chống lại việc xác minh là những công cụ đáng lo ngại.

Sau khi bạn hài lòng, hãy đến ứng dụng figmascope để xuất context bundle Figma và sử dụng với Claude Code hoặc Cursor.