REST APIs — إزاي التطبيقات بتتكلم مع بعض من غير واجهة رسومية

ليه ظهرت الفكرة دي أصلاً؟

في الأول، المواقع كانت كل حاجة فيها HTML جاهز من السيرفر. بس مع ظهور تطبيقات الموبايل، الـ Single Page Applications، والتكاملات بين خدمات مختلفة، احتجنا طريقة “منظّمة” ليها قواعد ثابتة عشان أي نظام (سواء موقع، تطبيق موبايل، أو خدمة تانية) يقدر يتكلم مع السيرفر ويفهم شكل الرد من غير ما يحتاج HTML خالص. الحل كان REST — Representational State Transfer، وهو أسلوب لتصميم الـ APIs مبني على HTTP نفسه.

المبادئ الأساسية اللي REST مبني عليها

1. Stateless: كل طلب لازم يكون مستقل تمامًا، مش معتمد على أي طلب سابق. السيرفر مش المفروض “يفتكر” حالتك بين الطلبات — أي معلومة محتاجها (زي التوكن) لازم تتبعت مع كل طلب.
2. Client-Server: فصل واضح بين العميل (Frontend) والخادم (Backend)، بحيث كل واحد يقدر يتطور لوحده من غير ما يأثر على التاني.
3. Cacheable: الردود ممكن تتخزن مؤقتًا لتحسين الأداء (نفس مبادئ الكاش اللي شرحناها قبل كده).
4. Uniform Interface: طريقة موحدة للتعامل مع أي مورد، بحيث الـ URLs والـ Methods بيتصرفوا بمنطق متوقع.
5. Resources: كل حاجة في النظام هي “مورد” (Resource) بيتم الوصول له عبر URL مميز ليه.

مثال عملي على REST API

https://api.example.com/users/123

• GET → يعرض بيانات المستخدم رقم 123.
• PUT → يحدّث بيانات المستخدم بالكامل.
• DELETE → يحذف المستخدم.

شكل الطلب والرد

POST /api/users HTTP/1.1
Host: api.example.com
Content-Type: application/json
Authorization: Bearer TOKEN

{
  "username": "islam",
  "email": "islam@example.com"
}

HTTP/1.1 201 Created
Content-Type: application/json

{
  "id": 123,
  "username": "islam"
}

طرق المصادقة في REST

• No Auth: API مفتوحة تمامًا (نادرة، وغالبًا تكون خطأ أكتر ما تكون قرار متعمد).
• API Key: GET /api/data?apikey=abc123 — لاحظ إن الـ key هنا موجودة في الـ URL نفسه، وده مشكلة لأنها بتتسجل في logs السيرفر، browser history، وReferer headers لو الصفحة فيها links خارجية.
• Bearer Token (غالبًا JWT): Authorization: Bearer <token> — الأسلوب الأشيع في الـ APIs الحديثة.
• Basic Auth: Authorization: Basic base64(user:pass) — لاحظ إن الـ base64 encoding مش تشفير، أي حد يعترض الطلب يقدر يفك التشفير فورًا لو الاتصال مش HTTPS.

ليه الـ REST APIs بقت أرض خصبة جدًا للثغرات؟

السبب الرئيسي إن الـ REST APIs بتكشف بنية الموارد بشكل صريح جدًا عبر الـ URL (زي /users/123، /orders/456)، وده بيخليها هدف مثالي لهجوم اسمه BOLA — Broken Object Level Authorization (كان معروف قبل كده باسم IDOR في سياق الـ APIs تحديدًا). فكرة الهجوم بسيطة: لو غيّرت الـ ID في الـ URL من 123 (بتاعك) لـ 124 (بتاع مستخدم تاني)، والسيرفر مش بيتحقق إن الـ token بتاعك فعلًا مسموحله يشوف المورد ده، هتقدر توصل لبيانات مش بتاعتك. الثغرة دي مصنّفة كأخطر ثغرة في OWASP API Security Top 10 لسنين متتالية.

أمثلة توسّعية على BOLA

• BOLA مش بس في الـ URL path — ممكن تكون جوا الـ request body كمان، زي {"user_id": 123, "action": "delete"}، وهنا الفحص أصعب لأنه مش ظاهر بشكل مباشر زي الـ URL.
• BOLA في الـ query parameters، زي ?account_id=456.
• BOLA في الـ response نفسه — أحيانًا الـ endpoint بيرجع بيانات أكتر مما المستخدم لازمه يشوف (Excessive Data Exposure)، حتى لو الطلب نفسه “مصرح” بيه.