كيفية حماية الـ API من الثغرات الشائعة برمجياً

تُعد واجهات برمجة التطبيقات API جزءًا أساسيًا من تطبيقات الويب الحديثة، وتطبيقات الهاتف، ومنصات SaaS، والأنظمة الداخلية، وخدمات الذكاء الاصطناعي.

لكن كل Endpoint جديد قد يضيف سطح هجوم جديدًا.

قد تبدأ المشكلة من سطر يبدو بسيطًا:

const user = await db.user.findUnique({
  where: {
    id: request.body.userId
  }
});

إذا كان الخادم يثق مباشرة في userId القادم من المستخدم، فقد يتمكن شخص من تغيير المعرف والوصول إلى بيانات حساب آخر، حتى لو كان لديه JWT صالح.

المشكلة هنا ليست في JWT، بل في غياب التحقق من الصلاحية على المورد المطلوب.

ولهذا يجب التعامل مع حماية API باعتبارها نظامًا متكاملًا يشمل:

• المصادقة Authentication.
• التفويض Authorization.
• التحقق من المدخلات.
• حماية البيانات في الاستجابات.
• حدود الاستهلاك.
• حماية المسارات الإدارية.
• إدارة الأسرار.
• مراقبة السلوك غير الطبيعي.
• حماية التكاملات الخارجية.
• مراجعة الإعدادات والإصدارات.

الفكرة الأساسية هي:

نجاح المستخدم في تسجيل الدخول لا يعني أنه يملك صلاحية تنفيذ كل عملية أو الوصول إلى كل مورد.

لماذا تفشل حماية API في تطبيقات الإنتاج؟

كثير من ثغرات API لا تبدأ بهجوم معقد أو كسر للتشفير.

قد تبدأ من:

• Endpoint يعيد حقولًا أكثر من المطلوب.
• معرف مستخدم يرسله Frontend ويثق به Backend.
• JWT صالحة لكن المستخدم لا يملك الصلاحية المطلوبة.
• مسار إداري مخفي في الواجهة لكنه غير محمي داخل الخادم.
• طلب بحث يسمح بإرجاع ملايين السجلات.
• API Key محفوظة داخل مستودع Git.
• Log يسجل Authorization Header.
• خدمة خارجية يثق التطبيق في بياناتها دون تحقق.
• إصدار قديم من API ما زال متاحًا على الإنترنت.

لذلك لا يكفي السؤال:

هل Endpoint يحتاج إلى Token؟

يجب أن تسأل:

من يطلب العملية؟ وما المورد المطلوب؟ وهل يملك هذا المستخدم صلاحية تنفيذ هذه العملية على هذا المورد؟ وما مقدار الموارد التي يمكن أن يستهلكها؟

تؤكد إرشادات OWASP أن حماية API تحتاج إلى فحص التحكم في الوصول على مستوى الـEndpoints والموارد، والتحقق من المدخلات، وتقييد الاستهلاك، وحماية الإعدادات والسجلات والتكاملات الخارجية. ([OWASP Cheat Sheet Series][2])

إطار العمل قبل تنفيذ أي تحسين أمني

قبل تعديل API، استخدم هذا الإطار:

النطاق

بدل قول:

سنؤمن API بالكامل.

ابدأ بهدف محدد:

سنراجع جميع Endpoints التي تستقبل معرفات موارد من المستخدم، ونضيف فحصًا واضحًا للملكية أو الصلاحية.

القياس

يمكن استخدام مؤشرات مثل:

• عدد محاولات الوصول المرفوضة.
• نسبة أخطاء المصادقة.
• عدد طلبات Rate Limit.
• زمن استجابة Middleware الأمني.
• عدد Endpoints التي تمت مراجعتها.
• عدد الحقول الحساسة التي أزيلت من Responses.
• عدد العمليات الإدارية التي أصبحت محمية.

المخاطر

اسأل:

• هل يمكن لمستخدم رؤية بيانات مستخدم آخر؟
• هل يمكنه تغيير بيانات لا يملكها؟
• هل يستطيع الوصول إلى وظيفة إدارية؟
• هل يمكنه استهلاك موارد مكلفة؟
• هل يمكنه كشف Secret أو Token؟
• هل يمكن أن يؤدي التحقق الجديد إلى منع مستخدمين شرعيين؟

الرجوع

قبل نشر التغيير:

• هل يمكن استخدام Feature Flag؟
• هل توجد مراقبة للأخطاء الجديدة؟
• هل يمكن إعادة سياسة الصلاحيات السابقة مؤقتًا؟
• هل توجد خطة لمعالجة الطلبات التي قد تتأثر؟

الفرق بين Authentication وAuthorization

هذا من أكثر الأخطاء شيوعًا.

المصادقة Authentication

تجيب عن السؤال:

من هو المستخدم؟

أمثلة:

• تسجيل الدخول بكلمة مرور.
• Session Cookie.
• JWT.
• Passkey.
• OAuth.

التفويض Authorization

يجيب عن السؤال:

ماذا يسمح لهذا المستخدم أن يفعل؟

أمثلة:

• هل يستطيع قراءة هذا المشروع؟
• هل يملك صلاحية حذف هذا الملف؟
• هل هو مدير؟
• هل يستطيع تصدير بيانات العملاء؟
• هل يستطيع تعديل إعدادات المؤسسة؟

يمكن أن تكون المصادقة ناجحة، بينما يجب رفض العملية بسبب غياب الصلاحية.

مثال:

المستخدم:
تم التحقق من هويته ✓

المورد:
طلب فاتورة تخص مستخدمًا آخر

النتيجة:
يجب رفض الطلب ✗

الخطأ الأول: الثقة في معرف المورد القادم من المستخدم

افترض وجود Endpoint:

GET /api/orders/123

قد يغيّر المستخدم الرقم:

GET /api/orders/124

إذا أعاد الخادم الطلب دون فحص ملكية الطلب، فقد يحصل المستخدم على بيانات شخص آخر.

هذه المشكلة ترتبط بما يعرف غالبًا باسم:

Broken Object Level Authorization – BOLA

أو في بعض السياقات:

IDOR

الحل ليس إخفاء المعرف أو تحويله إلى رقم عشوائي فقط.

يجب أن يتحقق الخادم من علاقة المستخدم بالمورد.

مثال غير آمن:

const order = await db.order.findUnique({
  where: {
    id: orderId
  }
});

return Response.json(order);

المشكلة:

يتم البحث بالمعرف فقط.

مثال أفضل:

const order = await db.order.findFirst({
  where: {
    id: orderId,
    userId: currentUser.id
  }
});

if (!order) {
  return Response.json(
    {
      error: "الطلب غير موجود أو لا تملك صلاحية الوصول إليه."
    },
    {
      status: 404
    }
  );
}

return Response.json(order);

في الأنظمة الأكثر تعقيدًا قد تكون الصلاحية مرتبطة بـ:

• المؤسسة.
• الفريق.
• المشروع.
• الدور.
• علاقة المستخدم بالمورد.

لذلك لا تجعل التحقق مجرد مقارنة ثابتة إذا كان نموذج الصلاحيات أكثر تعقيدًا.

الخطأ الثاني: اعتبار JWT تصريحًا كاملًا

JWT قد تساعد في إثبات هوية المستخدم، لكنها لا تعني:

اسمح للمستخدم بكل شيء.

مثال غير آمن:

const token = await verifyToken(request);

if (!token) {
  return new Response(
    "Unauthorized",
    {
      status: 401
    }
  );
}

await deleteUser(
  request.body.userId
);

وجود Token صالح لا يثبت أن المستخدم يملك صلاحية حذف الحساب المطلوب.

مثال أفضل:

const currentUser = await requireUser(
  request
);

const targetUserId =
  request.body.userId;

const allowed =
  await canDeleteUser({
    actorId: currentUser.id,
    targetUserId
  });

if (!allowed) {
  return Response.json(
    {
      error: "ليس لديك صلاحية لتنفيذ هذه العملية."
    },
    {
      status: 403
    }
  );
}

await deleteUser(
  targetUserId
);

القاعدة:

المصادقة تحدد الهوية، أما التفويض فيحدد العملية المسموح بها.

الخطأ الثالث: حماية الواجهة وترك Backend مفتوحًا

قد تخفي واجهة التطبيق زر:

حذف المستخدم

عن المستخدم العادي.

لكن المستخدم يستطيع إرسال طلب HTTP مباشرة إلى Endpoint إذا لم يكن Backend يتحقق من الصلاحية.

مثال:

DELETE /api/admin/users/123

إخفاء الزر ليس آلية أمنية.

الحماية يجب أن تكون داخل الخادم:

const currentUser =
  await requireUser(request);

if (
  currentUser.role !== "admin"
) {
  return Response.json(
    {
      error: "Forbidden"
    },
    {
      status: 403
    }
  );
}

لكن في الأنظمة الكبيرة، قد يكون فحص دور واحد غير كافٍ.

قد تحتاج إلى صلاحيات أدق مثل:

users.read
users.delete
billing.manage
projects.export

الخطأ الرابع: إعادة بيانات أكثر من المطلوب

قد يحتوي نموذج المستخدم على:

{
  id,
  name,
  email,
  passwordHash,
  role,
  internalNotes,
  resetToken
}

إذا أعدت النموذج كاملًا:

return Response.json(
  user
);

فقد تظهر حقول لا ينبغي إرسالها.

لا تعتمد على إزالة الحقول الحساسة بعد إنشاء Response.

استخدم Allowlist واضحة.

مثال:

return Response.json({
  id: user.id,
  name: user.name,
  email: user.email
});

أو حدد الحقول داخل Query:

const user =
  await db.user.findUnique({
    where: {
      id: currentUser.id
    },
    select: {
      id: true,
      name: true,
      email: true
    }
  });

القاعدة:

أرسل فقط الحقول التي يحتاجها العميل، وليس كل ما هو موجود في قاعدة البيانات.

الخطأ الخامس: Mass Assignment

قد يستقبل الخادم بيانات المستخدم:

{
  "name": "Ahmed",
  "role": "admin"
}

إذا تم تمرير البيانات مباشرة:

await db.user.update({
  where: {
    id: currentUser.id
  },
  data: requestBody
});

فقد يتم تعديل حقل لا يجب أن يتحكم به المستخدم.

الحل:

استخدم Schema تحدد الحقول المسموح بها.

مثال:

const allowedData = {
  name: body.name,
  avatarUrl: body.avatarUrl
};

await db.user.update({
  where: {
    id: currentUser.id
  },
  data: allowedData
});

لا تجعل كل حقل موجود في Model قابلًا للتعديل من API.

الخطأ السادس: ضعف التحقق من المدخلات

لا تثق في:

• Query Parameters.
• Request Body.
• Headers.
• أسماء الملفات.
• البيانات القادمة من API خارجية.
• قيم يرسلها Frontend.

تحقق من:

• النوع.
• الطول.
• النطاق.
• التنسيق.
• القيم المسموح بها.
• حجم الطلب.

مثال باستخدام Zod:

import { z } from "zod";

const updateProfileSchema =
  z.object({
    name: z
      .string()
      .trim()
      .min(2)
      .max(80),

    bio: z
      .string()
      .trim()
      .max(500)
      .optional()
  });

const body =
  await request.json();

const result =
  updateProfileSchema.safeParse(
    body
  );

if (!result.success) {
  return Response.json(
    {
      error:
        "بيانات الطلب غير صالحة."
    },
    {
      status: 400
    }
  );
}

التحقق لا يمنع كل الثغرات، لكنه يقلل وصول البيانات غير المتوقعة إلى منطق التطبيق.

الخطأ السابع: قبول طلبات ضخمة بلا حدود

قد يسمح Endpoint برفع ملفات أو إرسال JSON كبير جدًا.

يمكن أن يؤدي ذلك إلى:

• استهلاك الذاكرة.
• زيادة تكلفة المعالجة.
• بطء التطبيق.
• استهلاك مساحة التخزين.
• تعطيل الخدمة.

ضع حدودًا على:

• حجم Body.
• حجم الملفات.
• عدد العناصر.
• طول النصوص.
• عدد النتائج المطلوبة.

مثال:

الحد الأقصى للملفات:
10 MB

الحد الأقصى للعناصر:
100

الحد الأقصى لطول النص:
10,000 حرف

استخدم استجابة مناسبة مثل:

413 Payload Too Large

عندما يتجاوز الطلب الحجم المسموح.

الخطأ الثامن: Rate Limiting عام وضعيف

قد تضيف حدًا واحدًا:

100 طلب في الدقيقة

لكل API.

لكن العمليات ليست متساوية.

مثال:

لذلك استخدم طبقات متعددة.

حد عام

يحمي البنية من الزيادة الكبيرة.

حد حسب المستخدم

يمنع حسابًا واحدًا من الاستهلاك المفرط.

حد حسب IP

يساعد على تقليل بعض الهجمات غير الموثقة.

حد حسب API Key

مفيد للتكاملات الخارجية.

حد خاص بالعملية

مثال:

تسجيل الدخول:
5 محاولات في الدقيقة

إرسال رمز:
3 مرات خلال 15 دقيقة

تصدير البيانات:
مرتان خلال ساعة

بحث AI:
20 طلبًا في الدقيقة

عند تجاوز الحد، يمكن استخدام:

429 Too Many Requests

لكن Rate Limiting ليست بديلًا عن المصادقة والتفويض.

الخطأ التاسع: استخدام API Key لحماية كل شيء

يمكن أن تساعد API Keys في:

• تعريف التطبيق.
• تحديد خطة الاستخدام.
• فرض حدود الاستهلاك.
• مراقبة التكاملات.

لكنها ليست دائمًا بديلًا عن:

• هوية المستخدم.
• الصلاحيات الدقيقة.
• المصادقة القوية.

لا تعتمد على API Key وحدها لحماية:

• بيانات مالية.
• بيانات شخصية حساسة.
• عمليات إدارية.
• إجراءات عالية التأثير.

كما يجب:

• تدوير المفاتيح.
• إبطال المفتاح عند الاشتباه.
• عدم وضعه داخل الكود.
• عدم إرساله داخل URL.
• عدم تسجيله داخل Logs.

الخطأ العاشر: كشف الأسرار داخل الكود أو Git

مثال خاطئ:

const API_KEY =
  "sk-live-example-secret";

حتى إذا حذفت المفتاح لاحقًا، قد يبقى داخل:

• تاريخ Git.
• نسخة منشورة.
• سجل Build.
• لقطة شاشة.
• ملف Backup.

استخدم Environment Variables:

const apiKey =
  process.env.API_KEY;

لكن لا تكتفِ بنقل السر إلى Environment Variable.

يجب أيضًا:

• تقييد الوصول.
• تدوير المفاتيح.
• استخدام مفاتيح مختلفة للبيئات.
• مراقبة الاستخدام.
• إبطال المفتاح عند التسريب.

الخطأ الحادي عشر: تسجيل Authorization Header

مثال خطير:

console.log({
  headers:
    request.headers
});

قد يسجل ذلك:

Authorization:
Bearer eyJ...

أو:

Cookie:
session=...

لا تسجل Headers كاملة دون تنقية.

مثال أفضل:

logger.info({
  requestId,
  method:
    request.method,
  path:
    new URL(
      request.url
    ).pathname
});

يمكن تسجيل:

• معرف الطلب.
• المسار.
• الطريقة.
• النتيجة.
• زمن التنفيذ.
• معرف المستخدم الداخلي عند الحاجة.

لكن تجنب:

• Tokens.
• Cookies.
• كلمات المرور.
• API Keys.
• بيانات الدفع.
• البيانات الشخصية غير الضرورية.

الخطأ الثاني عشر: رسائل أخطاء تكشف تفاصيل داخلية

مثال غير آمن:

{
  "error": "Database connection failed",
  "host": "db-production.internal",
  "stack": "..."
}

قد تساعد هذه التفاصيل المهاجم على فهم البنية الداخلية.

استخدم رسالة عامة:

{
  "error": "حدث خطأ داخلي."
}

وسجل التفاصيل داخل نظام Logs آمن.

مثال:

try {
  await processRequest();
} catch (error) {
  logger.error({
    error,
    requestId
  });

  return Response.json(
    {
      error:
        "حدث خطأ داخلي.",
      requestId
    },
    {
      status: 500
    }
  );
}

الخطأ الثالث عشر: الثقة في Frontend لتطبيق تسلسل العمليات

افترض أن عملية الشراء تمر بالمراحل:

إنشاء الطلب
↓
الدفع
↓
التأكيد

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

لكن المستخدم يستطيع استدعاء Endpoint الأخير مباشرة.

يجب أن يتحقق الخادم من حالة العملية:

if (
  order.status !== "paid"
) {
  return Response.json(
    {
      error:
        "لا يمكن تأكيد الطلب قبل الدفع."
    },
    {
      status: 409
    }
  );
}

لا تفترض أن ترتيب الأزرار في الواجهة يفرض ترتيب العمليات على API.

الخطأ الرابع عشر: ضعف حماية Webhooks

Webhooks تستقبل طلبات من خدمات خارجية.

لا تفترض أن أي طلب وصل إلى Endpoint هو طلب موثوق.

يجب التحقق من:

• التوقيع.
• وقت الطلب.
• منع إعادة الإرسال عند الحاجة.
• مصدر الخدمة.
• نوع الحدث.
• شكل البيانات.

مثال مفاهيمي:

const signature =
  request.headers.get(
    "x-signature"
  );

const valid =
  verifyWebhookSignature({
    body: rawBody,
    signature,
    secret:
      process.env
        .WEBHOOK_SECRET
  });

if (!valid) {
  return Response.json(
    {
      error:
        "Invalid signature"
    },
    {
      status: 401
    }
  );
}

لا تستخدم JSON.stringify() بعد تحليل البيانات إذا كانت آلية التوقيع تتطلب الـRaw Body الأصلي.

الخطأ الخامس عشر: الثقة غير الآمنة في API خارجية

قد يتعامل التطبيق مع بيانات خدمة خارجية على أنها موثوقة.

لكن قد تكون الخدمة:

• مخترقة.
• أعادت بيانات غير متوقعة.
• أعادت Redirect.
• بطيئة.
• أعادت Response ضخمة.
• أرسلت بيانات غير صالحة.

تحقق من البيانات القادمة من الخدمات الخارجية كما تتحقق من مدخلات المستخدم.

أضف:

• Timeout.
• حدود حجم.
• تحقق Schema.
• معالجة Redirects.
• Allowlist للمصادر عند الحاجة.
• إعادة محاولة محدودة.

مثال:

const controller =
  new AbortController();

const timeout =
  setTimeout(
    () =>
      controller.abort(),
    5000
  );

try {
  const response =
    await fetch(
      externalUrl,
      {
        signal:
          controller.signal
      }
    );

  if (!response.ok) {
    throw new Error(
      "External API failed"
    );
  }
} finally {
  clearTimeout(
    timeout
  );
}

الخطأ السادس عشر: SSRF عند جلب رابط من المستخدم

قد يسمح Endpoint للمستخدم بإرسال رابط:

{
  "url": "https://example.com/file"
}

ثم ينفذ الخادم:

await fetch(
  body.url
);

إذا لم يتم التحقق من الرابط، فقد يحاول المهاجم إجبار الخادم على الاتصال بعناوين أو خدمات داخلية.

الحل يعتمد على البنية، لكنه قد يشمل:

• Allowlist للنطاقات.
• رفض العناوين الداخلية.
• التحقق من DNS.
• منع Redirects غير الموثوقة.
• عزل خدمة الجلب.
• تحديد Timeout وحجم Response.

لا تعتمد على فحص نصي بسيط مثل:

url.startsWith(
  "https://"
);

لأن HTTPS وحده لا يعني أن الوجهة آمنة.

الخطأ السابع عشر: CORS واسع أكثر من اللازم

مثال:

Access-Control-Allow-Origin: *

قد يكون مناسبًا لبعض APIs العامة، لكنه يحتاج إلى دراسة عند وجود:

• Cookies.
• بيانات مستخدم.
• صلاحيات حساسة.
• Credentials.

لا تستخدم إعدادات CORS واسعة دون معرفة:

• من يستطيع استدعاء API؟
• هل تستخدم Cookies؟
• هل تحتاج Origins محددة؟
• هل تسمح بطرق HTTP غير ضرورية؟
• هل تسمح Headers أكثر من اللازم؟

CORS ليست بديلًا عن المصادقة أو التفويض.

الخطأ الثامن عشر: نسيان الإصدارات القديمة وEndpoints التجريبية

قد يكون لديك:

/api/v1/users
/api/v2/users
/api/debug
/api/test
/api/admin-old

لكن الفريق يراقب الإصدار الجديد فقط.

احتفظ بجرد واضح يشمل:

• Hosts.
• API Versions.
• Endpoints.
• طرق HTTP.
• حالة كل Endpoint.
• مالك الخدمة.
• تاريخ الإيقاف.
• مستوى الحساسية.

عند إيقاف إصدار قديم:

• حدد تاريخًا.
• أخطر العملاء.
• راقب الاستخدام.
• أزل المسارات فعليًا.
• لا تترك Endpoint قديمًا دون مراقبة.

حماية API الخاصة بـAI Agents

عندما يستخدم AI Agent أدوات أو APIs، تصبح الصلاحيات أكثر حساسية.

لا تمنح Agent:

صلاحية كاملة

لمجرد أن النموذج يحتاج إلى تنفيذ مهام متعددة.

استخدم:

• أدوات محددة.
• صلاحيات محدودة.
• حدود تكلفة.
• Timeouts.
• موافقة بشرية للعمليات الحساسة.
• سجل تدقيق.
• قيود على الموارد.

مثال:

const allowedTools = [
  "searchDocuments",
  "createDraft"
];

const requiresApproval = [
  "deleteAccount",
  "sendPayment",
  "publishContent"
];

إذا كان Agent يستطيع استدعاء API إدارية، يجب أن يتحقق Backend من صلاحيات العملية نفسها، لا من مجرد أن الطلب جاء من Agent.

للتوسع في هذا الجانب، راجع:

دليل نشر AI Agents في بيئات الإنتاج بدون كوارث تشغيلية

كيف تنظم طبقات الحماية؟

يمكن تصور الطلب بهذا الشكل:

Request
↓
HTTPS
↓
Rate Limit
↓
Authentication
↓
Input Validation
↓
Authorization
↓
Business Rules
↓
Database
↓
Response Allowlist
↓
Audit Log

كل طبقة تعالج نوعًا مختلفًا من المخاطر.

لا تتوقع من JWT أن تحل مشكلة:

• Mass Assignment.
• تسريب البيانات.
• Rate Limiting.
• SSRF.
• ضعف التحقق من المدخلات.

ولا تتوقع من Rate Limiting أن تحل مشكلة:

• صلاحيات المستخدم.
• الوصول إلى بيانات مستخدم آخر.
• كشف الحقول الحساسة.

اختبارات أمنية يجب إضافتها

لا تختبر فقط:

المستخدم يطلب بياناته
→ نجاح

اختبر أيضًا:

المستخدم يطلب بيانات مستخدم آخر
→ رفض

المستخدم العادي يستدعي Endpoint إداري
→ رفض

المستخدم يرسل حقل role
→ تجاهل أو رفض

المستخدم يرسل Body ضخمة
→ رفض

المستخدم يتجاوز Rate Limit
→ 429

Token غير صالحة
→ 401

Token صالحة لكن بدون صلاحية
→ 403

Webhook بتوقيع خاطئ
→ رفض

طلب خارجي ببيانات غير متوقعة
→ رفض

اكتب اختبارات للحالات الفاشلة، وليس Happy Path فقط.

قائمة فحص قبل النشر

المصادقة

• جميع Endpoints غير العامة تتطلب مصادقة مناسبة.
• لا توجد Tokens ثابتة داخل الكود.
• لا يتم تسجيل Tokens أو Cookies.
• توجد سياسة لانتهاء الجلسات أو Tokens.
• توجد طريقة لإبطال بيانات الاعتماد عند الحاجة.

التفويض

• يتم فحص الصلاحيات داخل Backend.
• يتم فحص ملكية كل مورد حساس.
• لا يعتمد الخادم على إخفاء الأزرار.
• يتم فحص الوظائف الإدارية.
• يتم اختبار المستخدم العادي مقابل المدير.

المدخلات

• يوجد Schema لكل Body مهمة.
• توجد حدود للطول والحجم.
• يتم رفض الحقول غير المتوقعة عند الحاجة.
• يتم التحقق من Query Parameters.
• يتم التحقق من البيانات القادمة من APIs خارجية.

البيانات

• تستخدم Responses Allowlist للحقول.
• لا تظهر Hashes أو Tokens.
• لا تظهر ملاحظات داخلية.
• لا يتم إرجاع Model كامل دون مراجعة.

الاستهلاك

• يوجد Rate Limit عام.
• توجد حدود للعمليات الحساسة.
• توجد حدود للبحث والتصدير.
• توجد حدود لحجم الطلبات.
• يتم مراقبة الارتفاع غير الطبيعي.

السجلات

• لا يتم تسجيل Authorization Header.
• لا يتم تسجيل Cookies.
• لا يتم تسجيل كلمات المرور.
• لا يتم تسجيل API Keys.
• تستخدم السجلات Request ID.
• توجد مراقبة لمحاولات الفشل.

الإعدادات

• تعمل API عبر HTTPS.
• CORS محددة حسب الحاجة.
• لا توجد Endpoints Debug مكشوفة.
• الإصدارات القديمة معروفة ومراقبة.
• الأسرار منفصلة حسب البيئة.

التكاملات

• يتم التحقق من Webhook Signatures.
• توجد Timeouts للخدمات الخارجية.
• توجد حدود لحجم Responses.
• لا يتم الوثوق ببيانات API خارجية دون تحقق.
• تتم مراجعة Redirects والوجهات الخارجية.

الخلاصة

حماية API لا تعتمد على إضافة JWT أو Middleware واحد.

الحماية الفعلية تحتاج إلى طبقات متكاملة:

1. إثبات هوية المستخدم.
2. فحص صلاحياته.
3. التحقق من ملكية المورد.
4. التحقق من المدخلات.
5. تقييد الاستهلاك.
6. حماية البيانات في Responses.
7. حماية الأسرار.
8. تأمين Webhooks والتكاملات الخارجية.
9. مراقبة السلوك والأخطاء.
10. اختبار الحالات غير المتوقعة.

أكثر الأخطاء خطورة ليست دائمًا أخطاء تشفير معقدة.

أحيانًا يكون الخلل:

المستخدم أرسل معرفًا، والخادم لم يسأل هل يملك حق الوصول إليه.

ابدأ بمراجعة Endpoints التي تتعامل مع:

• بيانات المستخدمين.
• المدفوعات.
• الملفات.
• الحسابات.
• الصلاحيات.
• العمليات الإدارية.
• التصدير.
• الذكاء الاصطناعي.

ثم أضف الحماية طبقة بعد طبقة، وقس النتائج بدل الاعتماد على الانطباع.

الأسئلة الشائعة

هل JWT وحده يكفي لحماية API؟

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

أين أضع Rate Limiting؟

ضع طبقة حماية مبكرة على مستوى Gateway أو Middleware، ثم أضف حدودًا خاصة للعمليات المكلفة أو الحساسة مثل تسجيل الدخول والبحث والتصدير وإرسال الرسائل.

ما الفرق بين Authentication وAuthorization؟

المصادقة Authentication تجيب عن سؤال من هو المستخدم، بينما التفويض Authorization يحدد ما الذي يسمح لهذا المستخدم بفعله والوصول إليه.

هل إخفاء زر الإدارة في الواجهة يكفي لحماية Admin API؟

لا. يجب تطبيق التحقق من الصلاحيات داخل Backend لأن المستخدم يستطيع إرسال طلبات API مباشرة دون استخدام واجهة التطبيق.

هل API Key بديل آمن عن المصادقة؟

ليس دائمًا. يمكن استخدام API Keys لتحديد التطبيقات أو فرض حدود استخدام، لكنها لا ينبغي أن تكون الحماية الوحيدة للموارد الحساسة أو عالية القيمة.

هل يجب التحقق من بيانات API خارجية؟

نعم. لا تفترض أن البيانات القادمة من خدمة خارجية آمنة أو صحيحة. تحقق من شكلها وحجمها وقيمها، واستخدم Timeouts وحدودًا مناسبة.

هل Rate Limiting يمنع كل الهجمات؟

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

اقرأ أيضًا

• كيفية اعتماد Passkeys في تطبيقك بدون إرباك المستخدمين
• دليل نشر AI Agents في بيئات الإنتاج بدون كوارث تشغيلية
• كيف تبني Automation موثوقًا بدون فوضى تشغيلية
• نموذج الثقة المعدومة للفرق الصغيرة
• عقود API بـ TypeScript
• قائمة فحص نشر Next.js على Vercel بدون أخطاء إنتاج