لقد أحدثت ثورة LLM تحولًا عميقًا في عملية إنشاء الأكواد البرمجية، مما أدى إلى ظهور “الترميز الحيوي”، حيث تحل مطالبات اللغة الطبيعية محل البرمجة التقليدية. يعمل هذا التحول النموذجي على تمكين جيل جديد من المنشئين (كثير منهم يتمتعون بخلفية تقنية قليلة أو معدومة) لإنشاء ونشر تطبيقات كاملة الوظائف بسهولة غير مسبوقة.
منصات رائدة مثل محبوب هم في طليعة هذه الحركة. لقد مكنوا من إنشاء ملايين التطبيقات، بدءًا من الأدوات الشخصية البسيطة وحتى الحلول على مستوى المؤسسات. تعتمد المؤسسات الآن على هذه المنصات لبناء روبوتات الدردشة الداخلية، وإنشاء عمليات أتمتة معقدة، والأهم من ذلك، تكليفها ببيانات الشركة الحساسة.
كجزء من مهمتنا لتحديد المخاطر الناشئة في مجال السحابة والذكاء الاصطناعي، قامت Wiz Research بالتحقيق في الوضع الأمني للتطبيقات التي تم إنشاؤها بواسطة منصات الترميز الديناميكي هذه. كانت النتائج التي توصلنا إليها مهمة. لقد اكتشفنا نمطًا من التكوينات الخاطئة الشائعة عالية التأثير ووجدنا ذلك 1 من كل 5 منظمات البناء على هذه المنصات، مما يعرض أنفسهم للمخاطر عن غير قصد.
والخبر السار هو أن هذه القضايا يمكن الوقاية منها بسهولة. يعرض هذا المنشور بالتفصيل المخاطر الأكثر شيوعًا التي وجدناها، كما يوفر إرشادات واضحة وقابلة للتنفيذ لمساعدتك في تأمين تطبيقاتك المشفرة.
اكتشفنا عيبًا شائعًا وهو التطبيقات التي تتعامل مع عملية المصادقة بأكملها – إدخال كلمة المرور والتحقق من صحتها – من جانب العميل، دون الاتصال بأي خادم خلفي. في هذه الحالات، يقوم المتصفح بتنزيل كافة التعليمات البرمجية المخصصة “لحماية” التطبيق، مما يعني أن كلمة المرور مضمنة مباشرة في ملفات JavaScript وتكون مرئية لأي شخص يقوم بفحصها.
فيما يلي مثالان عمليان مجهولان لهذا الخلل الذي رأيناه في البرية:
المثال أ: سلسلة مضمنة ككلمة المرور
// Anonymized example of client-side validation
isAuthenticated: e,
isLoading: n,
login: s => s === "welcometoredacted" ? (t(!0),
localStorage.setItem("app-auth-token", "authenticated"),
!0) : !1,
logout: () =>
t(!1),
localStorage.removeItem("app-auth-token")
ماذا يحدث في الكود:
تتحقق وظيفة تسجيل الدخول مما إذا كانت كلمة المرور (كلمات المرور) المقدمة مساوية تمامًا للسلسلة “welcometoredacted”. إذا كانت متطابقة، فسيتم تعيين علامة مصادقة في LocalStorage. كلمة المرور مرئية بوضوح لأي شخص يشاهد الكود المصدري للتطبيق.
المثال ب: كلمة المرور في متغير
// Anonymized example using a variable for the password
const pC = "marketingdocs2025"
const ic = "my-app-auth-secret";
function vC(children: e)
// ... state and effects const o = l => l === pC ? (n(!0),
localStorage.setItem(ic, "authenticated"), r("password"), !0) : !1 // ... ماذا يحدث في الكود:
كلمة المرور "marketingdocs2025" يتم تعيينه أولاً إلى متغير pC. تقوم وظيفة تسجيل الدخول بعد ذلك بمقارنة مدخلات المستخدم (l) لهذا المتغير. على الرغم من أنها ليست مقارنة سلسلة مباشرة داخل الوظيفة، إلا أنه يتم تعريف متغير كلمة المرور في نفس الملف من جانب العميل، مما يسهل على المهاجم العثور عليه واستخدامه.
يشترك هذان المثالان الواقعيان في نفس الخلل الأساسي. إنهم يتعاملون مع متصفح المستخدم كبيئة موثوقة للمصادقة، وهو ليس كذلك. سواء كانت كلمة مرور واحدة كسلسلة، أو كلمة مرور مخزنة في متغير، فإن النتيجة متطابقة؛ يتم شحن الأسرار مباشرة إلى العميل.
علاوة على ذلك، يعتمد كلا المثالين على وضع علامة بسيطة يمكن التنبؤ بها LocalStorage (يحب "authenticated" أو "true") لإدارة الجلسة.
وهذا يخلق مسارًا ثانيًا، غالبًا ما يكون أسهل، للمهاجمين. لا يحتاج المهاجم إلى الاهتمام بنموذج تسجيل الدخول على الإطلاق؛ يمكنهم قراءة الكود لمعرفة القيمة المتوقعة LocalStorage، وتعيينه يدويًا باستخدام أدوات المطورين الخاصة بالمتصفح، والحصول على وصول فوري وغير مصرح به.
حل:
فرض المصادقة من جانب الخادم. التأكد من أن جميع قرارات المصادقة والترخيص يتم اتخاذها على خادم خلفي، ويجب أن يرسل التطبيق من جانب العميل فقط بيانات الاعتماد المقدمة من المستخدم إلى الخادم للتحقق من صحتها؛ ولا ينبغي أبدًا أن تحتوي على المنطق أو البيانات المطلوبة للتحقق من صحتها بنفسها.
أفضل طريقة هي فرض المصادقة من جانب الخادم مع موفري الخدمة مثل OAuth أو Cognito، والتأكد من أن مطالبات الذكاء الاصطناعي تتعامل دائمًا مع التعليمات البرمجية من جانب العميل على أنها مكشوفة للعامة.
لقد عملنا مع Lovable للمساعدة في فرض تغيير سريع في النظام العالمي للنظر في الأسرار من جانب العميل التي تنطوي على مخاطر أمنية وتصرفات غير مرغوب فيها. لمزيد من الإرشادات، راجع أفضل ممارسات Lovable بشأن أمان المصادقة.
بخلاف بيانات اعتماد المستخدم، وجدنا في كثير من الأحيان أسرارًا حساسة أخرى مثل مفاتيح واجهة برمجة التطبيقات التابعة لجهات خارجية وبيانات اعتماد حساب الخدمة المشفرة مباشرةً في ملفات JavaScript من جانب العميل، والتي غالبًا ما تبدو كما يلي:
const h$ = "sk-proj-FSAFCREDACTEDOVY7EfDD-XIMrVayZub7TakA"; function Pc() localStorage.removeItem("openai_api_key"), localStorage.setItem("openai_api_key", h$); const t = h$.slice(-4); console.log(`✅ OpenAI key successfully updated and working (ending in $t)`)
حل:
الحل هو وكيل جميع استدعاءات واجهة برمجة التطبيقات (API) التابعة لجهات خارجية من خلال واجهة خلفية آمنة – وهو دور تتم معالجته بشكل مثالي بواسطة Supabase Edge Functions في تطبيق محبوب. قم بتخزين مفاتيح API وأسرارك بشكل آمن في Supabase Secrets، ثم اطلب من الكود من جانب العميل الخاص بك استدعاء وظيفة Edge الخاصة بك، والتي تسترد المفتاح في وقت التشغيل وتعيد توجيه الطلب إلى خدمة الجهة الخارجية. يضمن هذا النمط البسيط عدم وصول بيانات الاعتماد الحساسة إلى المتصفح مطلقًا، مما يزيل خطر التعرض لها كما رأينا في العديد من الحالات عبر التطبيقات المشفرة.
تعمل منصات Vibe-coding على تسهيل ربط التطبيقات بقواعد بيانات قوية مثل Supabase، التي تستخدم أمان مستوى الصف (RLS) للتحكم في الوصول إلى البيانات. ومع ذلك، وجدنا أن المطورين غالبًا ما ينفذون سياسات RLS متساهلة بشكل مفرط أو ينسون تمكينها على الإطلاق عبر الجداول الحساسة، مما يؤدي إلى تسريب المعلومات السرية والخاصة.
مثال: سربت لعبة مؤسسية مشفرة جميع معلومات تحديد الهوية الشخصية (PII) وعناوين IP الخاصة بمستخدميها والمزيد عندما أرسل اللاعبون تفاصيل شخصية
قد يبحث المهاجمون عن التطبيقات التي تكشف مفتاح Anon Supabase الخاص بهم في جافا سكريبت الخاصة بهم، ويبدو الأمر مشابهًا لذلك.
const AR = (e, t, n) => new NR(e,t,n)
, IR = "https://plomwredacted.supabase.co"
, MR = "eyJhbGciredactediIsInR5cCI6IkpXVCJ9.redacted.redacted"
, Bi = AR(IR, MR,
auth:
storage: localStorage,
persistSession: !0,
autoRefreshToken: !0
)
الآن، يحتاجون إلى التحقق من أذونات خدمة Supabase، وسرد جميع الجداول والتحقق من 1 × 1 إذا كان هناك أي منها يكشف عن بيانات حساسة. لقد قمنا بعمل ماسح ضوئي بسيط لذلك يعمل بالمنهجية التالية:
# Get the OpenAPI schema to discover all tables
curl -X GET "https://YOUR-PROJECT.supabase.co/rest/v1/" \
-H "apikey: YOUR_API_KEY" \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json"
# Test each table
for table in $tables; do
echo "=== Testing table: $table ==="
response=$(curl -s -w "HTTPSTATUS:%http_code" \
"$SUPABASE_URL/rest/v1/$table?limit=5" \
-H "apikey: $API_KEY" \
-H "Authorization: Bearer $API_KEY" \
-H "Content-Type: application/json")
http_code=$(echo $response | tr -d '\n' | sed -e 's/.*HTTPSTATUS://')
body=$(echo $response | sed -E 's/HTTPSTATUS:[0-9]3$//')
if [ "$http_code" = "200" ]; then
echo "✅ ACCESSIBLE - Sample data:"
echo "$body" | jq '.' 2>/dev/null || echo "$body"
# Check for sensitive fields
sensitive=$(echo "$body" | jq -r 'if length > 0 then .[0] | keys[] else empty end' 2>/dev/null | grep -iE "(email|phone|password|token|secret|ip|address)" || true)
if [ ! -z "$sensitive" ]; then
echo "⚠️ SENSITIVE FIELDS DETECTED: $sensitive"
fi
else
echo "❌ Not accessible (HTTP $http_code)"
fi
echo
done
حل:
اعتماد سياسة “الرفض الافتراضي” للوصول إلى البيانات. عند تكوين قواعد أمان قاعدة البيانات مثل RLS، ابدأ دائمًا بسياسة ترفض الوصول بالكامل. بعد ذلك، اكتب قواعد واضحة ومختبرة بدقة لمنح الوصول فقط إلى البيانات الضرورية بناءً على معرف المستخدم المصادق عليه أو دوره. يجب إجبار كل استعلام في قاعدة البيانات على المرور عبر عوامل التصفية المقيدة هذه. يوفر Lovable إرشادات مفصلة حول منع التعرض للبيانات عبر Supabase RLS.
إن سرعة التشفير الديناميكي تجعله خيارًا مثاليًا لإنشاء أدوات داخلية ولوحات معلومات إدارية وبيئات مرحلية. ومع ذلك، لاحظنا العديد من الحالات التي تم فيها نشر هذه التطبيقات على الإنترنت العام دون مصادقة. وهذا يجعلها قابلة للاكتشاف من قبل المهاجمين الذين ينشطون تطبيقات الويب للمسح الضوئي وبصمات الأصابع لتحديد تلك التي تم إنشاؤها باستخدام منصات Vibe-Coding محددة.
باستخدام تقنية بسيطة لبصمات الأصابع، بحثنا عن تطابقات “lovable.app” ومجموعة إضافية من سلاسل التعريف، والتي أسفرت عن العديد من التطبيقات المشفرة التي لم يكن المقصود منها أبدًا أن تكون مواجهة علنية. وشملت هذه:
-
مواقع وهمية تحتوي على بيانات حقيقية دون فرض أي مصادقة
-
قواعد المعرفة الداخلية تسرب معلومات الملكية
-
تم تدريب Chatbots الداخلية على البيانات الحساسة
وأكثر…
حل:
قم دائمًا بفرض المصادقة على أي تطبيق يتعامل مع البيانات الحساسة أو المعلومات الداخلية لضمان عدم ظهور البيانات للعامة. كل شيء يبدأ بالرؤية. كمؤسسة، يجب أن تعرف جميع التطبيقات المشفرة التي يتفاعل معها المطورون لديك. ومن هناك، قم بفرضها لتكون مخصصة فقط للمعلومات العامة دون أي حساسية لها – على الأقل عندما لا يتم فرض المصادقة.
إن تحديد المخاطر الأمنية ليس سوى الخطوة الأولى. لدفع التغيير الهادف عبر مشهد Vibe-Coding بأكمله، تتعاون Wiz Research بشكل نشط مع الأنظمة الأساسية الرائدة في هذا المجال لتعزيز الممارسات الآمنة.
وخير مثال على ذلك هو تعاوننا مع فريق الأمان Lovable. لقد شاركنا أبحاثنا حول أنماط التكوين الخاطئ الشائعة هذه، واستجابة لذلك، قاموا بإنشاء دليل شامل لأفضل ممارسات الأمان على موقعهم على الويب.
يوفر هذا الدليل لمستخدميه خطوات واضحة وقابلة للتنفيذ لتجنب المخاطر الدقيقة المفصلة في بحثنا، وهو بمثابة شهادة على كيفية تعاملهم مع أمان المستخدمين على محمل الجد. يعد النهج الاستباقي والتعاوني أمرًا بالغ الأهمية لتأمين نظام Vibe-Coding البيئي من مصدره من خلال تمكين المطورين من البناء بشكل آمن من البداية.
بالنسبة لعملاء Wiz، يعد تحديد تطبيقات Vibe-Coding التي يحتمل أن تكون معرضة للخطر أمرًا سهلاً. يمكنك بسهولة عرض جميع تطبيقات Lovable التي تواجه الجمهور من خلال الاستعلام أدناه في بوابة Wiz.
ابحث عن تطبيقاتك المحبوبة في Wiz
منصات Vibe-Coding تعد جزءًا أساسيًا من تطوير البرمجيات الحديثة، مما يمكّن المؤسسات من الابتكار بوتيرة غير مسبوقة. ومع ذلك، تنشئ هذه الأنظمة الأساسية نموذجًا جديدًا للمسؤولية المشتركة حيث يعتمد أمان التطبيق بشكل كبير على تنفيذه. قد يؤدي أي تكوين خاطئ إلى تعريض البيانات الحساسة للخطر وتعريض المؤسسة لمخاطر كبيرة. في منشور المدونة هذا، قمنا بوصف أربعة تكوينات خاطئة شائعة في ترميز الاهتزاز وقدمنا نصائح حول كيفية علاجها. وتشمل هذه التكوينات الخاطئة المصادقة من جانب العميل، والأسرار المشفرة، وسياسات الوصول إلى البيانات غير الآمنة، وانكشاف التطبيقات الداخلية. يمكن أن يؤدي تنفيذ أفضل الممارسات المذكورة أعلاه إلى تقليل مساحة الهجوم في مؤسستك بشكل كبير وتأمين تطبيقاتك. نحن نقدر التعاون مع Lovable، التي أظهرت التزامًا عميقًا بتحسين أمان عملائها كجزء من هذا البحث.
احصل على تقرير حالة أمان التعليمات البرمجية من Wiz
