بعد التحدث مع زميلي @owengot، إليك وصفًا أكثر تفصيلاً للمشكلة.
توجد تطبيق ويب مبني على Vue.js لا يحتوي على مكون خادم نشط خاص به. بل هو تطبيق ويب مستقل يستخدم واجهة برمجة تطبيقات Discourse، لذا فإن Discourse يعمل بمثابة الخادم. تشمل حالات الاستخدام استطلاعات الرأي أو النماذج المستقلة، حيث يتم نشر المحتوى في مواضيع Discourse تحت حساب المستخدم. بدا أن القدرة على إنشاء مثل هذا البرنامج دون الحاجة إلى مكونات خادم مخصصة هي بنية معمارية جيدة لهذه الاستخدامات، لذا نود في أفضل الأحوال تجنب القيام بأي شيء “من جانب الخادم”.
الآن، تعمل عملية الحصول على مفتاح مستخدم عبر واجهة برمجة التطبيقات (User-API key) كما هو متوقع، لكن اكتشف @owengot أن خطوة توليد مفتاح خاص في JavaScript تستغرق وقتًا طويلاً (تصل إلى 10 ثوانٍ، فهي غير فعالة في JavaScript…). ثم اكتشف حيلة مفادها أنه يمكن استخدام نفس المفتاح الخاص لعدة مستخدمين، لذا قام بتخزينه في ملف على المضيف الذي يستضيف التطبيق ويب، والذي يخدم أيضًا الملفات الثابتة الأخرى للتطبيق (مثل ملفات JS و CSS وما إلى ذلك). هذا يجعل العملية سريعة… لكن الآن أصبح المفتاح الخاص (1) مشتركًا و(2) مخزنًا بشكل مكشوف، مع وجود رابط يمكن الوصول إليه علنًا. يبدو ذلك، أمم، مخيفًا 
لذلك قلت إنه يجب أن نسأل فريق Discourse حول الآثار الأمنية لهذه الحيلة. أرى بديلين أساسيين:
-
إذا كان هذا المفتاح الخاص يُستخدم “فقط” لتشفير الحمولة (payload)، فيمكننا العيش مع ذلك لأننا أيضًا نقوم بتشفير الاتصال عبر SSL/HTTPS.
-
لكن إذا كان معرفة هذا المفتاح الخاص يسمح بطريقة ما بحساب مفتاح مستخدم واجهة برمجة التطبيقات الناتج الذي يُستخدم لاحقًا للنشر تحت حساب شخص ما في Discourse، فسيكون هذا بالطبع يجعل هذه الحيلة غير مقبولة.