لاستخدام أي أداة Figma خارجية، تُولّد رمز وصول شخصي في إعدادات Figma وتلصقه في الأداة. هذا أمر أساسي. كل تكامل مع Figma يطلبه.
ما لا يدركه معظم الناس تماماً: هذا الرمز لا يقرأ "ملفاً واحداً". إنه يقرأ كل ملف يمكن لحسابك الوصول إليه. كل ملف خاص. كل مكتبة تنظيمية. كل مشروع مشترك. النطاق الافتراضي لـ PAT في Figma هو سطح القراءة الكامل لحسابك.
بالنسبة للمصمم الفردي ذي الحساب الشخصي، هذا خطر معتدل. لمصمم في مؤسسة مع مكتبات تصميم مشتركة تحتوي على منتجات غير مُصدَرة وأصول العلامة التجارية وأدوات داخلية — إنه خطر كبير. ولهؤلاء المصممين، "لصقت رمز Figma في هذه الأداة التي وجدتها" هي حادثة أمنية.
figmascope مصمم بحيث لا تحدث هذه الحادثة.
ما يمنحه PAT في Figma
مصادقة Figma API مستندة إلى PAT. رمز يُصادق بوصفك أنت. لا تفرض API نطاق تحديد كل ملف على مستوى الرمز — إنها تفرض الوصول للملف بناءً على أذونات حسابك. إذا كان حسابك يستطيع عرض ملف، يمكن للـ PAT قراءته عبر API.
نطاق PAT الافتراضي يمنح صلاحية قراءة لـ:
- جميع الملفات التي أنشأتها
- جميع الملفات المشتركة معك
- جميع الملفات في المشاريع والفرق التي أنت عضو فيها
- مكتبات المكونات المنشورة التي يستخدمها فريقك
أدخلت Figma نوع رمز أكثر تحديداً في 2023 — رموز يمكنك تحديد نطاقات المنح فيها. لكن واجهة المستخدم تفترض الرمز الواسع افتراضياً، ومعظم الدروس التعليمية تطلب منك توليد رمز دون تحديد النطاق. في الممارسة، معظم PATs المتناثرة في تاريخ حافظة المصممين هي رموز قراءة كاملة.
نموذج التهديد للأدوات التي تقبل PAT
أداة تقبل PAT لـ Figma ولها خادم خلفي تواجه تهديداً محدداً: الخادم الخلفي يخزن رمزك (لاستدعاء Figma نيابةً عنك)، وهذا التخزين هدف. إذا تم اختراق الخادم الخلفي، كل PAT مخزّن هناك يُخترق. إذا حدث اختراق لقاعدة بيانات الخادم، كل وصول Figma للمستخدمين يُخترق.
هذا ليس افتراضياً. اختراقات تخزين رموز OAuth حدثت لكثير من الخدمات. النمط هو: المستخدم يمنح الوصول، الخدمة تخزن الرمز، الخدمة تُخترق، المهاجم يستخرج الرموز، المهاجم الآن لديه وصول لكل ما تستطيع هذه الرموز الوصول إليه. لرموز Figma في مؤسسة، "كل ما تستطيع الوصول إليه" هو نظام التصميم الكامل.
الأدوات المستندة إلى خادم خلفي يجب أن تحل هذه المشكلة. الجيدة منها تفعل: تشفير في حالة الراحة، رموز قصيرة العمر، سير عمل إعادة المصادقة، تسجيل التدقيق. الحل الصحيح مشكلة هندسة أمان على مستوى المؤسسة. معظم الأدوات لا تحلها بشكل صحيح؛ إنها فقط لم تُخترق بعد.
أكثر تخزين آمن للرموز هو عدم التخزين أصلاً. إذا كانت معماريتك لا تُثبّت الرمز أبداً، لا يوجد شيء لاختراقه. هذا هو الاختيار المعماري الذي يتخذه figmascope — وهو ليس مجرد ميزة، إنه نموذج الأمان بأكمله.
معمارية figmascope
يعمل figmascope بالكامل في المتصفح. لا يوجد خادم خلفي. لا توجد قاعدة بيانات. لا توجد إدارة جلسات، لا حسابات مستخدمين، لا طبقة تخزين رموز. التطبيق عبارة عن حزمة HTML/CSS/JS ثابتة تُقدَّم من CDN. عند استخدامه، تحدث الحوسبة في تبويب متصفحك. لا يُرسَل شيء إلى خوادم figmascope لأنه لا توجد خوادم figmascope.
سير عمل PAT يعمل كما يلي:
- تُدخل PAT في حقل الإدخال.
- القيمة تُخزَّن في متغير إغلاق JavaScript — ربط
letJS عادي داخل وحدة التطبيق. - لا يُكتَب أبداً في
localStorage. لا يُكتَب فيsessionStorage. لا يُعيَّن كـ cookie. لا يُكتَب فيindexedDB. لا يُرسَل إلى أي URL بخلاف نقطتي Figma API. - عند إجراء تصدير، يُمرَّر الرمز كرأس
X-Figma-Tokenفي استدعاءاتfetch()إلىapi.figma.comوشبكة CDN لـ Figma لأصول الصور. - عند إغلاق أو إعادة تحميل التبويب، يُحرَّر ذاكرة JS. الرمز يختفي.
هذه دورة الحياة الكاملة. لا استمرارية في أي مكان. لا إرسال عبر الشبكة إلا مباشرة إلى Figma.
إنفاذ سياسة أمان المحتوى
لجعل خاصية "لا يُرسَل إلا إلى Figma" قابلة للإنفاذ لا مجرد مُؤكَّدة، ينشر figmascope سياسة أمان محتوى تقيّد 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 تعرض جميع PATs النشطة. الرموز التي ولّدتها لمشروع انتهى يجب إلغاؤها. رمز ولّدته لـ figmascope منذ ستة أشهر ولم تستخدمه منذ ذلك الحين يمكن إلغاؤه وإعادة توليده في المرة القادمة عند الحاجة.
لا تلصق الرموز في أدوات ذات خوادم خلفية إلا إذا تحققت من وضعها الأمني. اسأل: هل لهذه الخدمة خادم خلفي؟ إذا نعم، أين وكيف تخزّن رمزي؟ إذا لم تكن الإجابة مُرضية، أو لم توجد إجابة، عامله كخطر. هذا ينطبق على كل أداة Figma، ليس figmascope فقط.
مستخدمو المؤسسات: استخدم حسابات مشتركة/خدمة حيثما أمكن. إذا استطاعت مؤسستك إنشاء حساب خدمة Figma بوصول للقراءة فقط لمشاريع محددة، فتوليد PATs من هذا الحساب بدلاً من حسابك الشخصي يُحدّد ما هو متاح لتلك المشاريع.
ما لا ندّعيه
المعمارية المستندة إلى المتصفح لـ figmascope تُقلّل سطح الهجوم لسرقة اعتماد جانب الخادم. لا تُلغي جميع المخاوف الأمنية:
- امتدادات المتصفح ذات الأذونات الواسعة يمكنها قراءة متغيرات JavaScript. إذا كان لديك امتدادات متصفح غير موثوقة، فإنها تمثل خطراً لأي اعتماد تُدخله في أي تطبيق ويب.
- متصفح مخترق (برمجيات خبيثة، XSS في صفحة أخرى تتجاوز العزل) يمكنه نظرياً قراءة ذاكرة التبويب، رغم أن تعزيل المتصفح الحديث يجعل الوصول عبر الأصول صعباً جداً.
- مشاركة الشاشة والتجسس البصري خارج نطاق أي معمارية.
لا ندّعي أن هذا بديل عن تدقيق الأمان على مستوى المؤسسة. ندّعي: المعمارية تجعل فئة محددة من الهجمات — اختراق قاعدة بيانات رموز جانب الخادم — مستحيلة هيكلياً بإزالة الخادم. هذا تخفيض ذي معنى في سطح الهجوم، ليس حصانة كاملة.
لماذا يهم المصدر المفتوح هنا
ادعاءات الأمان بلا قيمة دون إمكانية التحقق. figmascope مرخّص بـ MIT والمصدر الكامل على GitHub. الادعاءات في هذا المنشور — لا كتابة في localStorage، لا إرسال للخادم الخلفي، رؤوس CSP — كلها قابلة للتحقق بقراءة الكود. يُظهر app.js عدم الكتابة في APIs تخزين المتصفح. يُظهر ملف الرؤوس CSP. تُظهر استدعاءات fetch بالضبط أي URLs تستقبل الرمز.
إذا كنا نكذب في أي من هذا، يستغرق اكتشاف الكذبة ثلاثين دقيقة. هذه هي النقطة. المصدر المفتوح ليس مجرد اختيار ترخيص؛ لأداة تتعامل مع اعتمادات، إنه الأساس الوحيد الصادق للادعاء الأمني.
يجب عليك التحقق من الأدوات التي تتعامل مع اعتماداتك. الأدوات التي تُقاوم التحقق هي تلك التي تستحق القلق.
بمجرد الاقتناع، انتقل إلى تطبيق figmascope لتصدير حزمة سياق Figma واستخدامها مع Claude Code أو Cursor.