الاستهلاك الآمن لـ APIs خارجية

مدخلات المستخدم المباشرة:  🔴 نتحقق منها دائمًا (تعلمناه في درس Input Validation)
استجابة API خارجي موثوق:   🟡 غالبًا نثق بها دون فحص كافٍ

لكن الطرف الثالث نفسه قد:
  - يتعرّض للاختراق (سلسلة التوريد تشمل تبعياتك الخارجية أيضًا)
  - يتغيّر سلوكه فجأة (تحديث API غير متوقع، حقل جديد، نوع بيانات مختلف)
  - يُعيد توجيه طلبك (Redirect) لخادم مختلف تمامًا عن الذي تظنه

// خدمة خارجية تُثري بيانات المستخدم (مثل التحقق من صحة عنوان بريد أو شركة)
app.post('/api/users/enrich', async (req, res) => {
  const response = await fetch(`https://enrichment-service.example.com/lookup?email=${req.body.email}`);
  const { companyName, jobTitle } = await response.json();

  // خطر: تخزين مباشر بلا تعقيم أو تحقق
  await db.$executeRawUnsafe(
    `UPDATE users SET company = '${companyName}' WHERE id = ${req.user.id}`
  );
  res.json({ companyName, jobTitle });
});

لو تعرّضت خدمة الإثراء الخارجية لاختراق (أو سمحت لأي مستخدم بتسجيل اسم
شركة بصياغة SQL خبيثة)، فإن companyName يحمل الآن Payload حقن SQL،
ينفَّذ مباشرة ضد قاعدة بياناتك بمجرد استخدام $executeRawUnsafe.

const enrichmentSchema = z.object({
  companyName: z.string().max(200).regex(/^[\p{L}\p{N}\s.,&-]+$/u),
  jobTitle: z.string().max(200),
});

const { companyName, jobTitle } = enrichmentSchema.parse(await response.json());
await db.user.update({ where: { id: req.user.id }, data: { company: companyName } });

// سيئ — يتبع أي تحويل يرسله الطرف الثالث تلقائيًا ويرسل بيانات حساسة معه
async function verifyPayment(paymentServiceUrl, cardToken) {
  const response = await fetch(paymentServiceUrl, {
    method: 'POST',
    body: JSON.stringify({ cardToken }), // بيانات حساسة بجسم الطلب
  });
  return response.json();
}

لو تعرّضت خدمة الدفع لاختراق جزئي، يمكن أن ترد بتحويل HTTP (301/307/308)
نحو خادم يتحكم به المهاجم. مكتبات fetch الافتراضية تتبع هذا التحويل
تلقائيًا وتعيد إرسال جسم الطلب — بما فيه cardToken — لخادم المهاجم.

async function verifyPayment(paymentServiceUrl, cardToken) {
  const TRUSTED_REDIRECT_HOSTS = ['payments.trusted-provider.com'];

  const response = await fetch(paymentServiceUrl, {
    method: 'POST',
    body: JSON.stringify({ cardToken }),
    redirect: 'manual',
  });

  if (response.status >= 300 && response.status < 400) {
    const target = new URL(response.headers.get('location'));
    if (!TRUSTED_REDIRECT_HOSTS.includes(target.hostname)) {
      throw new Error('تحويل غير موثوق من مزوّد الدفع — تم الرفض');
    }
    // أعد الطلب صراحة للوجهة المتحقق منها فقط، لا لأي وجهة أخرى
  }

  return response.json();
}

سيناريو من العالم الحقيقي: تطبيق يتكامل مع خدمة استضافة كود خارجية
ويعرض "اسم المستودع" في تقارير داخلية. مهاجم ينشئ مستودعًا باسم يحوي
صياغة SQL أو HTML خبيثة. عند سحب قائمة المستودعات عبر API الخدمة
الخارجية وعرضها أو تخزينها دون تعقيم، يُنفَّذ المحتوى الخبيث محليًا —
سواء كحقن قاعدة بيانات أو كـ XSS عند العرض بالمتصفح.

قبل الربط مع أي API خارجي:
  ✅ قيّم وضعه الأمني (شهادات، سجل اختراقات سابقة، توثيق أمني)
  ✅ افرض TLS لكل اتصال — لا استثناءات

عند استهلاك الاستجابة:
  ✅ تحقق من الشكل (Schema Validation) قبل أي استخدام أو تخزين
  ✅ عامل كل حقل نصي كمدخل غير موثوق (لا فرق عن مدخل مستخدم مباشر)
  ✅ لا تتبع Redirects تلقائيًا — تحقق من الوجهة أولًا
  ✅ لا تنفّذ استعلامات ديناميكية ببيانات خارجية (parameterized queries دائمًا)
  ✅ حدّد Timeout قصير — تبعية بطيئة لا يجب أن تُبطئ نظامك كاملًا

المراقبة المستمرة:
  ✅ راقب تغيّر سلوك الـ API الخارجي (حقول جديدة، أنواع بيانات مختلفة)
  ✅ خطة بديلة (Fallback) لو توقفت الخدمة الخارجية أو تصرّفت بشكل غريب