Browser-Based Tools में PAT Security — figmascope आपके Figma Token की सुरक्षा कैसे करता है

किसी भी third-party Figma tool को use करने के लिए, आप Figma की settings में एक Personal Access Token generate करते हैं और इसे tool में paste करते हैं। यह table stakes है। हर Figma integration इसके लिए पूछता है।

जो बात अधिकांश लोग पूरी तरह register नहीं करते: वह token "एक file" नहीं पढ़ता। यह हर file read करता है जिसे आपका account access कर सकता है। हर private file। हर organizational library। हर shared project। Figma PAT का default scope आपके पूरे account का read surface है।

Personal account वाले एक individual designer के लिए, यह moderate risk है। NDA-covered designs, brand assets, और internal tooling वाली shared design libraries के साथ किसी enterprise में staff designer के लिए — यह significant है। और उन designers के लिए, "मैंने अपना Figma token इस tool में paste किया जो मुझे मिला" एक security event है।

figmascope इस तरह designed है कि वह event न हो।

Figma PAT क्या grant करता है

Figma का API authentication PAT-based है। एक token आपके रूप में authenticate होता है। API token level पर per-file scoping enforce नहीं करता — यह आपके account की permissions के based पर file access enforce करता है। अगर आपका account कोई file view कर सकता है, तो PAT API के माध्यम से उसे read कर सकता है।

Default PAT scope read access grant करता है:

• सभी files जो आपने create की हैं
• सभी files जो आपके साथ shared हैं
• सभी files उन projects और teams में जिनके आप member हैं
• Published component libraries जो आपकी team use करती है

Figma ने 2023 में एक more scoped token type introduce किया — ऐसे tokens जहां आप select कर सकते हैं कि कौन से scopes grant करने हैं। लेकिन UI broad token पर default करता है, और अधिकांश tutorials scope specify किए बिना token generate करने के लिए कहते हैं। Practice में, designers के clipboard history में floating अधिकांश PATs full-read tokens हैं।

PAT-accepting tools के लिए threat model

एक tool जो Figma PAT accept करता है और backend रखता है एक specific threat face करता है: backend आपका token store करता है (Figma को आपकी behalf पर call करने के लिए), और वह storage एक target है। अगर backend compromise हो जाता है, वहां store हर PAT compromise हो जाता है। अगर backend में database breach होता है, हर user का Figma access breach हो जाता है।

यह hypothetical नहीं है। OAuth token storage breaches कई services के साथ हुए हैं। Pattern यह है: user access grant करता है, service token store करता है, service breach होती है, attacker tokens exfiltrate करता है, attacker के पास अब वह सब access है जिन तक वे tokens पहुंच सकते हैं। Enterprise में Figma tokens के लिए, "वह सब जिन तक वे tokens पहुंच सकते हैं" full design system है।

Backend-based tools को यह problem solve करनी होती है। अच्छे वाले करते हैं: encryption at rest, short-lived tokens, re-auth workflows, audit logging। इसे properly solve करना एक enterprise-grade security engineering problem है। अधिकांश tools इसे properly solve नहीं करते; उनका बस अभी तक breach नहीं हुआ है।

सबसे secure token storage कोई storage नहीं है। अगर आपकी architecture token को कभी persist नहीं करती, तो breach करने के लिए कुछ नहीं है। यह वह architectural choice है जो figmascope बनाता है — और यह सिर्फ एक feature नहीं है, यह पूरा security model है।

figmascope की architecture

figmascope पूरी तरह browser में चलता है। कोई backend server नहीं है। कोई database नहीं है। कोई session management नहीं, कोई user accounts नहीं, कोई token storage layer नहीं। Application एक static HTML/CSS/JS bundle है जो CDN से serve होती है। जब आप इसे use करते हैं, computation आपके browser tab में होती है। figmascope servers को कुछ भी नहीं भेजा जाता क्योंकि कोई figmascope servers नहीं हैं।

PAT flow इस तरह काम करता है:

1. आप input field में अपना PAT enter करते हैं।
2. Value एक JavaScript closure variable में store होती है — application module के अंदर एक regular JS let binding।
3. यह कभी localStorage में नहीं लिखी जाती। कभी sessionStorage में नहीं। Cookie के रूप में कभी set नहीं होती। indexedDB में कभी नहीं लिखी जाती। दो Figma API endpoints को छोड़कर किसी भी URL पर कभी नहीं भेजी जाती।
4. जब आप export करते हैं, token api.figma.com और image assets के लिए Figma CDN पर fetch() calls में X-Figma-Token header के रूप में pass होता है।
5. जब आप tab बंद या reload करते हैं, JS memory release हो जाती है। Token चला जाता है।

यह complete lifecycle है। कहीं भी कोई persistence नहीं। Figma को directly को छोड़कर कोई network transmission नहीं।

Content Security Policy enforcement

"केवल Figma को भेजा गया" property को केवल asserted की बजाय enforceable बनाने के लिए, figmascope एक Content Security Policy deploy करता है जो connect-src को दो permitted hosts पर lock करता है:

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

CSP browser-enforced है। भले ही page में कोई script injection vulnerability हो, browser किसी भी token को third-party host पर भेजने के attempt को block कर देगा। किसी अन्य destination के लिए network requests browser level पर fail होती हैं, machine छोड़ने से पहले।

यह defense in depth है। Application code already token को कहीं और नहीं भेजता। CSP इसे ऐसा बनाता है कि application code इसे कहीं और भेज नहीं सकता भले ही वह try करे।

Recovery path

क्योंकि token केवल in-memory है, recovery trivial है: tab बंद करें। Token चला गया। कोई revocation step नहीं, कोई "delete account" नहीं, कोई "sign out" नहीं। Tab closed = token gone।

यह operational security perspective से भी सही behavior है। Short-lived credential windows exposure minimize करती हैं। आप figmascope खोलते हैं, PAT paste करते हैं, exports करते हैं, tab बंद करते हैं। वह window जिसमें PAT accessible है exactly उस browser session की duration है। इसकी तुलना एक backend tool से करें जहां आपका token महीनों तक stored रह सकता है, active और accessible, जब तक आप explicitly इसे revoke नहीं करते।

Tool की परवाह किए बिना recommendations

figmascope की in-memory architecture के साथ भी, अच्छी PAT hygiene मायने रखती है:

Scoped token use करें। Figma अब explicit scopes के साथ tokens support करता है। figmascope exports जैसे read-only operations के लिए, एक read-only token पर्याप्त है और अगर यह कभी exposed हो तो blast radius limit करता है। केवल file_read scope के साथ token generate करें, default broad scope नहीं।

जो tokens आप actively use नहीं करते उन्हें revoke करें। Figma की settings सभी active PATs दिखाती हैं। जो tokens आपने किसी ended project के लिए generate किए थे उन्हें revoke करना चाहिए। छह महीने पहले figmascope के लिए generate किया गया token जिसे तब से use नहीं किया है उसे revoke किया जा सकता है और अगली बार जरूरत होने पर regenerate किया जा सकता है।

Backends वाले tools में tokens paste न करें जब तक आपने उनका security posture verify न कर लिया हो। पूछें: क्या इस service का backend है? अगर हां, तो यह मेरा token कहां और कैसे store करता है? अगर जवाब satisfying नहीं है, या कोई जवाब नहीं है, तो इसे risk के रूप में treat करें। यह हर Figma tool पर apply होता है, केवल figmascope पर नहीं।

Enterprise users: जहां available हो shared/service accounts use करें। अगर आपका organization एक Figma service account specific projects तक read-only access के साथ create कर सकता है, तो अपने personal account की बजाय उस account से PATs generate करना उन projects तक accessible चीज़ों को limit करता है।

हम क्या claim नहीं करते

figmascope की browser-only architecture server-side credential theft के लिए attack surface minimize करती है। यह सभी security concerns eliminate नहीं करती:

• Broad permissions वाले browser extensions JavaScript variables read कर सकते हैं। अगर आपके पास untrusted browser extensions हैं, वे किसी भी web application में आप enter करने वाले किसी भी credential के लिए risk represent करते हैं।
• एक compromised browser (malware, किसी अन्य page पर XSS जो isolation escape करता है) potentially in-tab memory read कर सकता है, हालांकि modern browser sandboxing cross-origin access को बहुत कठिन बनाता है।
• Screen sharing और shoulder surfing किसी भी architecture के scope से बाहर हैं।

हम यह claim नहीं कर रहे कि यह enterprise-grade security auditing का substitute है। हम claim कर रहे हैं: architecture एक specific class of attack — server-side token database breach — को server को eliminate करके structurally impossible बनाती है। यह attack surface में meaningful reduction है, complete immunity नहीं।

Open source यहाँ क्यों मायने रखता है

Security claims बिना verifiability के बेकार हैं। figmascope MIT-licensed है और full source GitHub पर है। इस post के claims — कोई localStorage writes नहीं, कोई backend transmission नहीं, CSP headers — सभी code read करके verifiable हैं। app.js browser storage APIs पर कोई writes नहीं दिखाता। Headers file CSP दिखाती है। fetch calls exactly दिखाते हैं कि कौन से URLs token receive करते हैं।

अगर हम इनमें से किसी के बारे में झूठ बोल रहे होते, तो झूठ find करने में तीस मिनट लगते। यही point है। Open source केवल license choice नहीं है; credentials handle करने वाले tool के लिए, यह security claim के लिए एकमात्र honest basis है।

आपको वे tools verify करने चाहिए जो आपके credentials handle करते हैं। जो tools verification resist करते हैं वे चिंता करने लायक हैं।

एक बार satisfied होने के बाद, अपना Figma context bundle export करने के लिए figmascope app पर जाएं और इसे Claude Code या Cursor के साथ use करें।