서드파티 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 흐름은 다음과 같이 작동합니다:
- 입력 필드에 PAT를 입력합니다.
- 값이 JavaScript 클로저 변수에 저장됩니다 — 애플리케이션 모듈 내부의 일반 JS
let바인딩. localStorage에 쓰이지 않습니다.sessionStorage에도 쓰이지 않습니다. 쿠키로 설정되지 않습니다.indexedDB에 쓰이지 않습니다. 두 Figma API 엔드포인트 외의 어떤 URL로도 전송되지 않습니다.- 내보내기를 할 때, 토큰은
api.figma.com과 이미지 에셋용 Figma CDN에 대한fetch()호출의X-Figma-Token헤더로 전달됩니다. - 탭을 닫거나 새로 고침하면 JS 메모리가 해제됩니다. 토큰이 사라집니다.
이것이 완전한 생명주기입니다. 어디에도 영속성이 없습니다. Figma에 직접 전송하는 것 외에 네트워크 전송이 없습니다.
Content Security Policy 강제
"Figma에만 전송" 속성을 단순히 주장하는 것이 아니라 강제할 수 있게 하기 위해, figmascope는 connect-src를 두 허용된 호스트로 잠그는 Content Security Policy를 배포합니다:
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가 표시됩니다. 끝난 프로젝트를 위해 생성한 토큰은 취소해야 합니다. 6개월 전에 figmascope를 위해 생성했고 그 이후 사용하지 않은 토큰은 취소하고 다음에 필요할 때 재생성할 수 있습니다.
보안 태세를 확인하지 않고는 백엔드가 있는 도구에 토큰을 붙여넣지 마세요. 물어보세요: 이 서비스에 백엔드가 있나요? 그렇다면 어디에서 어떻게 내 토큰을 저장하나요? 답이 만족스럽지 않거나 답이 없으면, 위험으로 취급하세요. 이것은 figmascope만이 아닌 모든 Figma 도구에 적용됩니다.
엔터프라이즈 사용자: 가능한 경우 공유/서비스 계정을 사용하세요. 조직이 특정 프로젝트에 대한 읽기 전용 접근 권한을 가진 Figma 서비스 계정을 만들 수 있다면, 개인 계정 대신 그 계정에서 PAT를 생성하면 접근 가능한 것을 해당 프로젝트로 제한합니다.
우리가 주장하지 않는 것
figmascope의 브라우저 전용 아키텍처는 서버 사이드 자격 증명 도난의 공격 표면을 최소화합니다. 모든 보안 우려를 제거하지는 않습니다:
- 광범위한 권한을 가진 브라우저 확장 프로그램은 JavaScript 변수를 읽을 수 있습니다. 신뢰할 수 없는 브라우저 확장 프로그램이 있다면, 그것은 어떤 웹 애플리케이션에 입력하는 모든 자격 증명에 대한 위험을 나타냅니다.
- 침해된 브라우저(다른 페이지의 악성 소프트웨어, XSS)는 잠재적으로 탭 내 메모리를 읽을 수 있지만, 현대 브라우저 샌드박싱은 교차 출처 접근을 매우 어렵게 만듭니다.
- 화면 공유와 어깨 너머 훔쳐보기는 어떤 아키텍처에서도 범위 밖입니다.
이것이 엔터프라이즈 수준의 보안 감사를 대체한다고 주장하지 않습니다. 주장하는 것은: 아키텍처가 특정 종류의 공격 — 서버 사이드 토큰 데이터베이스 침해 — 을 서버를 제거함으로써 구조적으로 불가능하게 만든다는 것입니다. 그것은 완전한 면역이 아닌 공격 표면의 의미 있는 감소입니다.
오픈 소스가 여기서 중요한 이유
보안 주장은 검증 가능성이 없으면 가치가 없습니다. figmascope는 MIT 라이선스이며 전체 소스가 GitHub에 있습니다. 이 글의 주장들 — localStorage 쓰기 없음, 백엔드 전송 없음, CSP 헤더 — 은 모두 코드를 읽음으로써 검증할 수 있습니다. app.js는 브라우저 저장소 API에 대한 쓰기를 보여주지 않습니다. 헤더 파일은 CSP를 보여줍니다. fetch 호출은 어떤 URL이 토큰을 받는지 정확히 보여줍니다.
우리가 이 중 어느 것에 대해 거짓말을 하고 있다면, 거짓을 찾는 데 30분이 걸릴 것입니다. 그것이 요점입니다. 오픈 소스는 단순한 라이선스 선택이 아닙니다; 자격 증명을 다루는 도구에 대해서는 보안 주장의 유일하게 솔직한 근거입니다.
자격 증명을 다루는 도구를 검증해야 합니다. 검증에 저항하는 도구들이 걱정할 가치가 있는 것들입니다.
만족하면 figmascope 앱으로 이동하여 Figma 컨텍스트 번들을 내보내고 Claude Code나 Cursor와 함께 사용하세요.