أمان البرمجة بالحدس: كيف تحمي تطبيقًا أنشأه الذكاء الاصطناعي

تجد مزيدًا من التعليمات حول استخدام Ailoot في الوثائق.

لماذا تُخترق التطبيقات المبنية بالذكاء الاصطناعي أكثر من غيرها؟#

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

جذر المشكلة بسيط. عندما تطلب من وكيل ذكاء اصطناعي «أنشئ لي تطبيقًا لحجز العملاء»، فإنه يجعل التطبيق يعمل بأسرع ما يمكن. أما الأمان فهو عمل إضافي لا يظهر في العرض التوضيحي. لذلك تُعدّ قاعدة البيانات مفتوحة، ويوضع مفتاح الدفع مباشرة في الشيفرة، ولا يوجد التحقق من «هل يحق لهذا المستخدم الوصول؟» إلا في المتصفح، حيث يمكن تجاوزه في ثانية.

السبب الثاني هو المنصات نفسها.

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

المنطق واضح: ينفّذ الوكيل git add . وgit push من دون أن ينظر، فيصبح ملف .env الذي يحتوي على مفاتيحك عامًا مع كل شيء آخر.

ما الدروس القاسية التي تعلّمها ممارسو البرمجة بالحدس بالفعل؟#

أفضل وسيلة للوقاية من الإهمال هي التعلّم من أخطاء الآخرين. إليك أربعة تقارير تستحق الاطلاع عليها قبل نشر مشروعك.

Lovable وRLS المعطّل. تنشئ منصة Lovable تطبيقات من أوصاف نصية. في عام 2025، اكتُشفت ثغرة منهجية في تطبيقاتها وأُسند إليها الرقم CVE-2025-48757. والسبب أن التطبيقات المُنشأة لم تتضمن قواعد وصول إلى قاعدة البيانات على مستوى الصفوف (RLS، موضح أدناه). فحص باحث عينة ووجد 303 نقاط وصول مكشوفة عبر 170 تطبيقًا. كُشفت الأسماء وأرقام الهواتف وحالات الدفع ومفاتيح API الخاصة بأشخاص آخرين، وحتى عناوين المنازل. وفي نحو 70 بالمئة من التطبيقات التي فُحصت، كان مستوى الحماية على مستوى الصفوف معطّلًا تمامًا.

Tea والبيانات الحساسة. فقد تطبيق Tea (للتقييمات المجهولة للأشخاص) نحو 72,000 صورة في يوليو 2025، منها 13,000 صورة سيلفي وصور لوثائق، ثم أكثر من مليون رسالة خاصة. وكان السبب التقني التخزين المفتوح وضعف عمليات التحقق من الوصول. ويستشهد مجتمع الأمن بتطبيق Tea مثالًا واضحًا: عندما يكون الإطلاق السريع أهم من التحقق من الأذونات، تكون البيانات الحساسة أول ما يتسرب.

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

جبهتان للأمان: أين تكمن ثغراتك تحديدًا؟#

عندما يتحدث الناس عن «أمان البرمجة بالحدس»، غالبًا ما يخلطون بين مخاوف مختلفة تمامًا. لنفصل بينها، لأن طرق الحماية منها مختلفة.

الجبهة الأولى—الوكيل نفسه. تشغّل وكيل ذكاء اصطناعي على حاسوبك وتمنحه الوصول إلى ملفاتك وطرفيتك ومفاتيحك وقاعدة بياناتك. تكمن المخاطرة في أن الوكيل ليس إنسانًا: فهو يتبع التعليمات حرفيًا ويبحث عن أقصر طريق، حتى إن كان ذلك الطريق خطيرًا. ويشمل هذا أيضًا احتمال «حقن» أمر شخص آخر في الوكيل عبر نص يقرؤه (ويُسمى هذا prompt injection).

الجبهة الثانية—التطبيق المكتمل. هذا هو ما نشرته ويستخدمه الناس. الهدف هو موقعك أو خدمتك المنشورة: يدخل المهاجمون إلى قاعدة بيانات مفتوحة، أو يرسلون طلبات زائفة، أو يخمّنون حسابات الآخرين. لا علاقة للوكيل بهذا؛ فقد تُركت الثغرة في وقت سابق، ويستغلها الآخرون.

تعبّر Anthropic، الشركة التي تقف وراء Claude، عن مبدأ الحماية الأساسي بهذه الطريقة، وهو صالح للجبهتين:

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

هل تريد أن يعمل الذكاء الاصطناعي بطريقة يمكن توقعها، وأن يتوقف عن التسبب لك بالمشكلات في كل مشروع جديد؟ قواعد الأمان جزء من Second Brain: دوّنها مرة واحدة في CLAUDE.md وسيتبعها الوكيل في كل طلب.

ما الذي يمكن لوكيل ذكاء اصطناعي فعله إذا وصل إلى حاسوبك؟#

أكثر المخاطر التي يُستهان بها هي وكيلك أنت عندما تكون أذوناته واسعة أكثر من اللازم. ولا تحتاج حتى إلى مخترق من الخارج. إليك مثالًا حديثًا من أواخر مايو 2026. احتاج وكيل Codex إلى أذونات المسؤول التي لم يكن المستخدم يملكها. لم يستسلم الوكيل؛ بل تفحّص ما حوله، ولاحظ أن المستخدم ينتمي إلى مجموعة docker، التي تعادل صلاحيات root فعليًا، ثم استخدم هذا الوصول.

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

ما الذي يمكنك فعله عمليًا، حتى إن لم تكن مبرمجًا؟

1. لا تشغّل الوكيل في وضع «السماح بكل شيء» على جهاز إنتاج

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

2. امنع الوكيل من قراءة الأسرار

   في Claude Code، يمكنك إعداد قاعدة تمنع الوصول إلى الملفات التي تحتوي على مفاتيح. وعندها لن تسمح الأداة للوكيل بفتح .env حتى لو حاول ذلك.

3. افصل مفاتيح الإنتاج

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

4. استخدم البيئة المعزولة للأداة

   تستطيع أدوات الذكاء الاصطناعي الحديثة تنفيذ الأوامر في عزلة (sandbox)، حيث لا يمكنها الوصول إلى بقية النظام. وفي Claude Code، يقلل هذا طلبات الأذونات بنحو 84 بالمئة، لذا فهو أكثر ملاءمة أيضًا.

تبدو قاعدة منع قراءة الأسرار في Claude Code تقريبًا هكذا—أضفها إلى إعدادات الأذونات:

{
  "permissions": {
    "deny": [
      "Read(.env)",
      "Read(**/.env)",
      "Bash(git push *)"
    ]
  }
}

أين يجب ألا تضع مفاتيح API وكلمات المرور أبدًا؟#

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

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

حجم المشكلة في عام 2025: أُضيف 28.65 مليون سر جديد بشكل مباشر إلى الشيفرة في المستودعات العامة، بزيادة قدرها 34 بالمئة عن العام السابق. وارتفعت تسريبات المفاتيح المخصصة لخدمات الذكاء الاصطناعي بنسبة 81 بالمئة. وتزيد البرمجة بالحدس المشكلة سوءًا لأن الوكيل ينفّذ الالتزام من دون أن ينظر.

ما الذي ينبغي أن تتحقق منه يدويًا الآن:

1. افتح ملف .gitignore الخاص بالمشروع

   تأكد من وجود سطر .env فيه. إذا لم يكن موجودًا، فأضفه قبل الالتزام الأول.

2. انتقل إلى مستودعك على GitHub

   تحقّق من عدم وجود ملف .env هناك. ويُعد البحث عن .env أو عن جزء من مفتاحك في المستودع طريقة سريعة للفحص.

3. إذا تسرّب مفتاح، فألغِه وأصدر بديلًا

   حذف الالتزام لا يكفي؛ فقد يكون المفتاح قد سُرق بالفعل. انتقل إلى الخدمة (مزود الدفع أو الخدمة السحابية أو مزود الذكاء الاصطناعي)، وألغِ المفتاح القديم وأصدر مفتاحًا جديدًا. تُسمى هذه العملية تدوير المفاتيح.

4. امنح المفاتيح الحد الأدنى من الأذونات

   إذا كان المفتاح مطلوبًا للقراءة فقط، فاجعله للقراءة فقط. عندها، حتى لو تسرّب، تقل البيانات التي يمكن سرقتها.

لماذا يستطيع الجميع رؤية قاعدة بياناتك من دون RLS؟#

إذا كنت تبني تطبيقًا على Supabase أو قاعدة بيانات مشابهة، فهذا أهم قسم. يشير RLS إلى Row Level Security، أي أمان مستوى الصف. وببساطة، هي قاعدة تحدد الصفوف التي تُعرض لمستخدم معين من الجدول. ومن دونها، يعرض جدول «الطلبات» طلبات جميع العملاء للجميع.

إليك الصياغة الواضحة التي تستخدمها وثائق Supabase نفسها:

وهذا هو الفخ الرئيسي لمن يمارس البرمجة بالحدس. عند إنشاء جدول بالنقر في لوحة تحكم Supabase، يُفعّل الحماية تلقائيًا. لكن عندما ينشئ الذكاء الاصطناعي الجدول—وهو يكتب أوامر SQL مباشرة في أغلب الأحيان—يظل RLS معطّلًا افتراضيًا. وهذا يعني أن الجدول الذي ينشئه الوكيل يكون على الأرجح مفتوحًا للإنترنت كله. وهذه بالضبط الطريقة التي تسرّبت بها بيانات تطبيقات Lovable الـ170.

ما الذي ينبغي فعله:

1. اسأل الوكيل مباشرة

   اكتب: «اعرض لي كل الجداول التي يكون فيها RLS معطّلًا». سيُنشئ الذكاء الاصطناعي قائمة؛ وتلك هي قائمة المهام التي عليك العمل عليها.

2. فعّل RLS في كل جدول يحتوي على بيانات المستخدمين

   وأضف سياسة وصول واحدة على الأقل، مثل «يمكن للمستخدم رؤية صفوفه هو فقط».

3. تحقّق من لوحة التحكم

   ينبغي أن يظهر في لوحة تحكم Supabase أن كل جدول يستخدم «RLS enabled». إذا كان المؤشر رماديًا أو أحمر، فهذا يعني أن الجدول مفتوح.

4. اختبر الأمر عمليًا

   سجّل الدخول بصفتك مستخدمًا عاديًا وحاول طلب بيانات شخص آخر. إذا رُفض الوصول، فهذا يعني أن السياسة تعمل.

لماذا لا تحميك عمليات التحقق من الأذونات في الواجهة؟#

من الأوهام الشائعة الاعتقاد بأن «المستخدمين العاديين لا يستطيعون رؤية زر المسؤول». المشكلة أن الزر مجرد صورة في المتصفح. ويمكن إرسال طلب مباشرة إلى الخادم من دون استخدام الزر. وإذا لم يُعِد الخادم التحقق من الأذونات، فسوف ينفّذ أمر شخص آخر.

من الأمثلة الكلاسيكية IDOR. تخيّل أنك فتحت طلبك عبر عنوان يحتوي على id=123. غيّره إلى id=124 وستتمكن من رؤية طلب شخص آخر لأن الخادم لم يتحقق من أنه طلبك فعلًا. وهذه من أكثر الثغرات شيوعًا في التطبيقات المبنية بالبرمجة بالحدس، كما كانت عمليات التحقق الضعيفة من الأذونات وراء تسريب Tea.

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

كيف تتحقق من الثغرات في الشيفرة إذا لم تكن مبرمجًا؟#

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

1. أمر /security-review في Claude Code. يفحص الفرع الحالي مرة واحدة بحثًا عن حقن SQL وXSS وثغرات التفويض وتسريب البيانات ومشكلات التبعيات. وقد شرحت خطوة بخطوة آلية عمله وطريقة ربط فحص تلقائي بكل تغيير في دليل منفصل حول مراجعة الأمان في Claude Code. والخلاصة هنا: إنه خط الدفاع الأول، ويُشغّل بأمر واحد.

2. إضافة security-guidance الرسمية. ثبّتها من سوق الإضافات الرسمي باستخدام /plugin install security-guidance@claude-plugins-official (يلزم Claude Code الإصدار 2.1.144 أو أحدث). تفحص الشيفرة في ثلاث مراحل: عند كل تعديل، وفي نهاية كل دور، وعند الالتزام. وتكتشف تجاوزات التفويض وIDOR وحقن التعليمات والتشفير الضعيف. لكن Anthropic صريحة بشأن حدودها:

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

للتوضيح: بدأت الجهات الرئيسية أيضًا تأخذ أمان الشيفرة المُنشأة بالذكاء الاصطناعي على محمل الجد. وفي إطار Project Glasswing، الذي توسّع في 2 يونيو 2026 ليشمل 150 مؤسسة، عثر الشركاء على أكثر من 10,000 ثغرة حرجة في وقت قصير باستخدام نماذج Anthropic. والمخاطر واضحة:

<figure>
<blockquote>
<p>نقدّر أن هجومًا كبيرًا قد يؤثر في أكثر من 100 million شخص لدى معظم الشركاء.</p>
</blockquote>
<figcaption>— Anthropic (Project Glasswing)، https://www.anthropic.com/news/expanding-project-glasswing</figcaption>
</figure>

## هل يمكنك الوثوق بالمهارات والإضافات من GitHub؟

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key takeaway">

الخلاصة الرئيسية

لا، ليس افتراضيًا—تحقّق قبل التثبيت. كل مهارة أو إضافة أو امتداد هو شيفرة كتبها شخص آخر، وسيشغّلها الوكيل على جهازك بصلاحياتك. أما المجموعة التي يتضمن اسمها كلمة «Anthropic» فقد أنشأها المجتمع فعلًا ولا علاقة لها بـ Anthropic. ويمكن لإضافة خبيثة أن تسرق مفاتيحك خلال دقائق، كما أن إزالة الحزمة لا تمحو آثارها دائمًا.

</div>

هنا تزداد الأمور تعقيدًا، لأن الخطر يأتي من أداة تثبّتها لأغراض الأمان. عندما تنفّذ `npx skills add ...` أو تثبّت إضافة، فأنت تجلب شيفرة شخص آخر، ثم يشغّلها الوكيل بصلاحياتك. إذا تعرّض مؤلفها للاختراق أو كانت الحزمة خبيثة منذ البداية، فستقع في مشكلة.

لنأخذ مجموعة المهارات الواردة في القسم السابق. يتضمن اسمها كلمة «Anthropic»، ما يجعلك تخفّض حذرك. لكن الوصف في مستودعها يقول بوضوح:

<figure>
<blockquote>
<p>هذا مشروع مجتمعي مستقل. وليس تابعًا لشركة Anthropic PBC.</p>
</blockquote>
<figcaption>— ملف README لمستودع mukul975،</figcaption>
</figure>

بعبارة أخرى، الاسم مضلل. المجموعة نفسها ناضجة ونظيفة حاليًا، لكن المبدأ لا يتغير: تثبّتها على مسؤوليتك. والتهديد ليس افتراضيًا. في مايو 2026، بقيت إضافة خبيثة لمحرر في السوق 18 دقيقة فقط، وتمكنت خلالها من سرقة كلمات المرور من تطبيقات إدارة كلمات المرور، ورموز GitHub، وإمكانية الوصول السحابي، وحتى إعدادات Claude Code من الأشخاص الذين ثبّتوها. وهناك تفصيل مزعج آخر: غالبًا ما تنجو هذه البرمجيات الخبيثة من الإزالة العادية للحزمة، وتعمل مجددًا في الجلسة التالية.

اتبعت عادة بسيطة أوصي بها لك أيضًا: تحقّق بنفسك قبل تثبيت أي مهارة من GitHub. قد يتعرض المؤلفون للاختراق، وقد تُختطف الحسابات، وقد تصل برمجيات خبيثة إلى مستودع. والتحقق هو وسيلتك للحماية.

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

## ما الذي ينقذك بعد الاختراق: النسخ الاحتياطي والتراجع

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key takeaway">

الخلاصة الرئيسية

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

</div>

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

وهذا يقود إلى قاعدتين.

**أنشئ نسخًا احتياطية باستمرار.** إذا احتوى تطبيقك على بيانات لا تود فقدانها، فإن النسخ مرة كل ثلاثة أيام وهم بالحماية. أعد إعداد نسخ احتياطية تلقائية مرة كل 30 دقيقة على الأقل. ويمكن تفعيل ذلك في معظم قواعد البيانات، ومنها Supabase، ببضع نقرات.

**git تأمين ضد الوكيل.** يحتفظ git بسجل الشيفرة، ويمكنك استعادة أي حالة كانت تعمل. عندما يعيد الوكيل كتابة شيء كان يعمل، يمكنك الرجوع إلى آخر إصدار صالح بدلًا من إصلاحه يدويًا. إذا حذف الذكاء الاصطناعي المشروع أو أفسده ولم تعرف كيفية استعادته، فراجع التقرير المنفصل: [ما العمل إذا حذف الذكاء الاصطناعي قاعدة البيانات](guide-032.md). وللحماية مسبقًا من تلف المشروع، راجع دليل [كيفية حماية Claude Code من إفساد المشروع](guide-154.md).

## قائمة تحقق أمنية قبل النشر

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key takeaway">

الخلاصة الرئيسية

قبل إتاحة تطبيقك للعامة، تحقّق من 10 عناصر: الأسرار في `.env` و`.gitignore`، وتفعيل RLS، والتحقق من الأذونات على جانب الخادم، وتواقيع webhook، والحد الأدنى من الامتيازات للمفاتيح والوكيل، والنسخ الاحتياطية الحديثة، وفحص الشيفرة بأداة، والحذر من مهارات الآخرين. هذه قائمة تحقق أساسية قبل النشر، دون نسبة تغطية مقاسة أو زمن إنجاز مضمون. تحقق من سيناريوهات الوصول الحقيقية في تطبيقك؛ فالعلامة أمام البند لا تثبت الحماية وحدها.

</div>

راجع هذه القائمة مباشرة قبل النشر، بالترتيب.

1.  **الأسرار في `.env`، وملف `.env` مدرج في `.gitignore`.** لا مفاتيح في الشيفرة. ولا ملف `.env` في مستودع عام.
2.  **المفاتيح بأقل قدر من الأذونات.** يجب أن يؤدي كل مفتاح ما هو مطلوب منه فقط. وتُفصل مفاتيح الإنتاج عن بيئة الوكيل.
3.  **RLS مفعّل** في جميع الجداول التي تحتوي على بيانات المستخدمين، وسياسات الوصول مُعدّة.
4.  **تحقّق من الأذونات على جانب الخادم** لكل عملية على البيانات. إخفاء زر في الواجهة لا يكفي. اختبر يدويًا تغيير `id` في العنوان.
5.  **التحقق من توقيع webhook.** يتحقق كل معالج للإشعارات الخارجية (المدفوعات والنماذج) من التوقيع.



6.  **تقييد معدل الطلبات** الواردة والعمليات المكلفة كيلا يمكن تخمين كلمات المرور بالقوة الغاشمة أو رفع فاتورتك.
7.  **لا يعمل الوكيل في وضع «السماح بكل شيء»** على جهاز يحتوي على مفاتيح الإنتاج. ويُمنع عليه قراءة `.env`.
8.  **النسخ الاحتياطية** متكررة ومختبرة؛ وقد جرّبت فعلًا استعادة البيانات بدلًا من الاكتفاء بالاعتقاد أن النسخ «موجودة في مكان ما».
9.  **فُحصت الشيفرة** باستخدام `/security-review` أو إضافة security-guidance. وأُصلحت النتائج.
10. **فُحصت مهارات الآخرين وإضافاتهم** قبل تثبيتها. ولم يُثبّت أي شيء «من دون تحقق».

<div class="aside" data-semantic="callout" role="note" aria-label="Tip">

نصيحة

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

</div>

## من أين تبدأ اليوم؟

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key takeaway">

الخلاصة الرئيسية

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

</div>

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

1.  **تحقّق من أسرارك.** افتح `.gitignore`، وتأكد من إدراج `.env`، ثم تحقّق من عدم وجود مفاتيح في المستودع العام. إذا تسرّب أي منها، فألغِه وأصدر بديلًا.
2.  **اسأل عن RLS.** قل للوكيل: «اعرض لي الجداول التي يكون فيها RLS معطّلًا»—وفعّله أينما خُزنت بيانات الناس.
3.  **اضبط نسخًا احتياطية متكررة.** حتى لا تخسر سوى دقائق بدلًا من أيام إذا حدث خطأ ما.

بعد ذلك، اتبع قائمة التحقق أعلاه مع نمو مشروعك وبدئه بالتعامل مع الأموال وبيانات الآخرين.

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

<div class="section" role="doc-bibliography" aria-label="Sources">

### المصادر

- [كيف تعزل Anthropic نموذج Claude (Anthropic Engineering)](https://www.anthropic.com/engineering/how-we-contain-claude)
- [توسعة Project Glasswing (Anthropic)](https://www.anthropic.com/news/expanding-project-glasswing)
- [Claude Code: الأذونات وقواعد المنع (الوثائق)](https://code.claude.com/docs/en/permissions)
- [إضافة security-guidance (وثائق Claude Code)](https://code.claude.com/docs/en/security-guidance)
- [Row Level Security (وثائق Supabase)](https://supabase.com/docs/guides/database/postgres/row-level-security)
- [أهم 10 مخاطر لتطبيقات LLM وفق OWASP 2025](https://genai.owasp.org/llm-top-10/)

</div>





لمواصلة العمل مع النماذج، يمكنك الانتقال إلى [Ailoot](https://ailoot.ai/).