بنيت تطبيقك بالذكاء الاصطناعي؟ 12 فحصًا أمنيًا قبل وصول المستخدمين الحقيقيين

الإجابة المختصرة: قد يعمل التطبيق المبني بأدوات الذكاء الاصطناعي بشكل ممتاز في العرض التجريبي، ومع ذلك يسمح لأي غريب بقراءة بيانات عملائك. قبل دعوة مستخدمين حقيقيين، افحص اثني عشر أمرًا، منها: المفاتيح السرية، وقواعد الوصول إلى قاعدة البيانات، والتحقق من الهوية في كل واجهة برمجية، والتخزين، والمدخلات، والمكتبات، والسجلات، والنسخ الاحتياطية. وإن لم تكن واثقًا من كل منها، فاطلب تدقيقًا مستقلًا للكود قبل الإطلاق، لا بعد وقوع الحادث.

غيّرت أدوات البرمجة بالذكاء الاصطناعي سرعة بناء النسخة الأولى. صار المؤسس في الإمارات أو السعودية أو مصر ينتقل من الفكرة إلى منتج يعمل خلال عطلة نهاية أسبوع باستخدام Lovable أو Bolt أو Replit أو Cursor أو Claude Code. هذا خبر جيد، لكن «التطبيق يعمل» و«التطبيق آمن لبيانات العملاء» اختباران مختلفان.

لماذا تحتاج التطبيقات المبنية بالذكاء الاصطناعي إلى فحص أمني خاص؟

لأن هذه الأدوات تركّز على أن يعمل الكود، لا على أن يكون آمنًا. وجدت Veracode أن 45% من مهام البرمجة بالذكاء الاصطناعي أنتجت ثغرة معروفة من قائمة OWASP Top 10 في 2025، دون تحسن يُذكر في 2026. وقد سرّبت تطبيقات حقيقية بيانات مستخدمين بسبب قواعد وصول غائبة أو تخزين مكشوف للعامة.

• اختبرت Veracode كودًا مولّدًا في 80 مهمة وبأربع لغات برمجة (تقرير 2025، تحديث 2026).
• في 2025، وجد فحص نشرته Semafor أن 170 من أصل 1,645 موقعًا مبنيًا على منصة شهيرة واحدة تكشف بيانات مستخدمين أو مفاتيح.
• وفي العام نفسه، سرّب تطبيق Tea نحو 72 ألف صورة من مساحة تخزين غير محمية (Reuters).

وكما قلنا في توقعاتنا لعام 2027، صار الكود رخيصًا في كتابته ومكلفًا في الثقة به.

ما الفحوص الاثنا عشر قبل الإطلاق؟

افحص: المفاتيح السرية، وقواعد الوصول إلى قاعدة البيانات، واختبار الحسابين، والتحقق من الصلاحيات على الخادم، وخصوصية الملفات، والتحقق من المدخلات على الخادم، وحدود المحاولات، والمكتبات، ونظافة الأخطاء والسجلات، وإعدادات CORS ووضع التطوير، ونسخًا احتياطية مجرّبة، وخريطة للبيانات الشخصية. وينبغي أن ينتهي كل فحص بعبارة: «نعم، وهذا دليلنا».

1. لا مفاتيح سرية في الواجهة أو المستودع

ابحث في كود الواجهة وملفات `.env` وسجل git كاملًا عن مفاتيح API ومفاتيح الدفع وكلمات مرور قواعد البيانات. وأي مفتاح نُشر يومًا يُعامَل كأنه مسرّب: غيّره، ولا تكتفِ بحذف السطر.

2. قواعد الوصول مفعّلة في كل جدول

إن كنت تستخدم Supabase أو Firebase أو ما يشبههما، فيجب تفعيل أمان مستوى الصفوف (أو قواعد الأمان) في كل جدول ومجموعة، مع ربطها بمعرّف المستخدم المسجّل. والقاعدة التي تقول «اسمح دائمًا» تساوي غياب القاعدة.

3. اختبر بحسابين وبلا حساب

أنشئ المستخدم (أ) والمستخدم (ب). وأنت مسجّل باسم (أ)، حاول قراءة سجلات (ب) وتعديلها وحذفها بتغيير المعرّفات في الرابط أو الطلب. ثم سجّل الخروج وكرّر المحاولة. هذا الاختبار وحده يكشف كثيرًا من أشيع تسريبات البيانات، وهو أول ما يبدأ به تدقيق الكود.

4. كل واجهة برمجية تتحقق من هوية المتصل

دوال الخادم ومسارات الإدارة يجب أن تتحقق من الهوية والصلاحيات على الخادم. فإخفاء زر في الواجهة ليس تحكمًا في الوصول.

5. الملفات خاصة افتراضيًا

صور الهويات والفواتير والمستندات الطبية مكانها مساحات تخزين خاصة تُعرض بروابط موقّعة قصيرة الصلاحية، لا روابط عامة يمكن تخمينها.

6. التحقق من المدخلات على الخادم

تحقق من نوع كل حقل وطوله وصيغته على الخادم، واستخدم الاستعلامات المُهيّأة (Parameterized Queries). فهنا تقع ثغرات حقن SQL وXSS التي رصدتها اختبارات Veracode.

7. حدود للمحاولات في الدخول والتسجيل ورموز OTP

من دونها، يستطيع برنامج آلي تخمين كلمات المرور أو استنزاف رصيد الرسائل أو سحب بياناتك في ليلة واحدة.

8. مكتبات حقيقية وحديثة وقليلة

قد تضيف أدوات الذكاء الاصطناعي حِزَمًا لا تحتاجها، أو إصدارات قديمة بثغرات معروفة، أو أسماء غير موجودة يمكن انتحالها. شغّل فحصًا للمكتبات واحذف ما لا تستخدمه.

9. الأخطاء والسجلات لا تكشف شيئًا

صفحات الخطأ في بيئة الإنتاج لا تعرض تفاصيل الكود أو المفاتيح، والسجلات لا تحفظ كلمات المرور أو بيانات البطاقات أو أرقام الهوية.

10. إعدادات CORS والترويسات ووضع التطوير مضبوطة بإحكام

اقصر CORS على نطاقاتك، وفعّل ترويسات الأمان المعتادة، وأوقف وضع التطوير، وتأكد أن ملفات source maps ومجلد `.git` غير متاحة للعامة.

11. نسخ احتياطية واستعادة مجرّبة

النسخة الاحتياطية التي لم تُجرَّب استعادتها مجرد أمنية، لا نسخة احتياطية. اعرف إلى أي مدى يمكنك الاسترجاع، وكم يستغرق ذلك.

12. اعرف ما البيانات الشخصية التي تحتفظ بها وأين

اكتب البيانات الشخصية التي تجمعها، ولماذا، وأين تُخزَّن، ومن يصل إليها. ففي الإمارات يسري قانون حماية البيانات الشخصية (المرسوم بقانون اتحادي رقم 45 لسنة 2021)، وفي مصر قانون حماية البيانات الشخصية رقم 151 لسنة 2020. *(هذه ليست استشارة قانونية؛ راجع مستشارك القانوني.)*

كيف تبدو النتيجة الجيدة؟

لا تحتاج إلى علامة كاملة لإطلاق نسخة أولى. تحتاج إلى: عدم وجود ثغرات حرجة مفتوحة، وقائمة مكتوبة بالمخاطر المقبولة مؤقتًا مع مسؤول وموعد لكل منها، وعادة ثابتة بتشغيل اختبار الحسابين وفحص المكتبات قبل كل إصدار. هذا يكفي لاستقبال مستخدمين حقيقيين بمسؤولية.

متى تستعين بمراجعة مستقلة؟

شغّل القائمة بنفسك أولًا، ثم استعن بمراجعة مستقلة قبل إدخال بيانات عملاء أو مدفوعات أو بيانات صحية أو بيانات أطفال، أو حين يطلب مستثمر أو عميل مؤسسي مراجعة تقنية، أو حين لا يستطيع أحد في الفريق شرح آلية التحكم في الوصول، أو حين يكون الكود قد مرّ بعدة أدوات أو جهات تطوير.

كيف نقارب الأمر

نبدأ باختبار الحسابين، ثم نقرأ قواعد الوصول والمفاتيح والمكتبات، ونسلّمك قائمة قصيرة مرتبة: ما يُصلَح قبل الإطلاق، وما يُصلَح قريبًا، وما هو سليم. وتدقيق الكود من فريتل مصمم لهذه اللحظة تحديدًا: مراجعة محددة النطاق تنتهي بتقرير مُقيَّم عن الجودة والأمان وقابلية الصيانة، وأهم الإصلاحات مرتبة حسب الأثر، ومكالمة شرح مدتها 30 دقيقة.

تريد رأيًا ثانيًا؟ تعرّف على تدقيق الكود، أو احجز مكالمة تعارف مجانية.

ونحن نشغّل برمجياتنا الخاصة في بيئة الإنتاج، مثل نظام Anvilium، فهذه هي الفحوص نفسها التي نطبقها على إصداراتنا.

دورك: هل أطلقت شيئًا بُني في معظمه بأدوات الذكاء الاصطناعي؟ أي الفحوص الاثني عشر سيفشل فيه أولًا؟ راسلنا على hello@fritill.com.

المصادر (رُوجعت في 10 نوفمبر 2026): تقريرا Veracode لأمان الكود المولّد بالذكاء الاصطناعي (2025 و2026)، وSemafor (مايو 2025)، وReuters (يوليو 2025)، وبوابة حكومة الإمارات بشأن قوانين حماية البيانات (u.ae).