# أمن منصة كفالة

## حدود البيانات

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

## المصادقة والصلاحيات

- Supabase Auth هو مصدر الجلسة.
- الدوران الوحيدان هما `admin` و`donor`.
- يدخل المسؤول بالبريد الإلكتروني من `/admin-login`، ويدخل المتبرع برقم الهاتف وكلمة المرور من `/login`.
- ينشئ المسؤول حساب المتبرع ويؤكد رقم الهاتف إدارياً؛ ولا يوجد بريد إلكتروني في مسار المتبرع.
- كل صفحة لوحة تستدعي تحققاً خادمياً من الدور وحالة الحساب.
- RLS مفعّل على كل جدول حساس، ولا يعتمد الأمان على إخفاء عناصر الواجهة.
- يرى المتبرع النشط الحالات والوثائق المرتبطة بعلاقة كفالة نشطة، ويرى سجلات الدفع والتحويلات والإيصالات التي تحمل معرف حسابه تحديداً.
- عند إيقاف حساب متبرع يُحظر حساب Auth وتمنع سياسات RLS الوصول إلى البيانات.
- تنتهي واجهة الجلسة بعد مدة خمول قابلة للضبط، وتظل سياسة رموز Supabase جزءاً من إعداد المشروع.

## الملفات الخاصة

- تحفظ الملفات داخل `public/uploads/orphans/<orphan-id>/documents` و`receipts` حتى يبقى لكل يتيم مجلد مستقل.
- يمنع `proxy.ts` كل وصول مباشر إلى `/uploads`، وتضيف `.htaccess` داخل المجلد حظراً دفاعياً عند النشر خلف Apache.
- وثائق الحالة اختيارية، وتقبل عند رفعها صور JPG/JPEG أو PNG أو WEBP فقط.
- إيصالات التحويل الجديدة صور فقط حتى يمكن عرضها كصور مصغرة آمنة؛ وتحفظ ملفات PDF القديمة التي رحلت للمراجعة دون إتلافها.
- يتحقق الخادم من الحجم والامتداد وMIME وتوقيع الملف، ويكتب الملف بصلاحية `0600`.
- الاسم الفعلي UUID ولا يُرجع للمستخدم، ولا توجد روابط عامة دائمة.
- إنشاء الحالة ووثائقها المتاحة ذري في قاعدة البيانات؛ وتحذف الملفات المرحلية عند فشل المعاملة.
- استبدال الوثيقة ذري، ولا يحذف الملف القديم من القرص إلا بعد نجاح تحديث قاعدة البيانات.
- يتحقق `/api/files/[id]` من المستخدم وحالة الحساب؛ وثائق الحالة تتطلب علاقة نشطة، وإيصال التحويل يتطلب تطابق معرف المتبرع مع التحويل نفسه.
- يجب اختبار أن `/uploads/...` يعيد 404 بعد كل تغيير في إعدادات الخادم أو الوكيل، وألا يضبط الخادم مسار الملفات كمسار static يتجاوز تطبيق Node.
- لا تُسجل المسارات الفعلية أو محتويات الوثائق في السجلات.

## أسرار البيئة

`SUPABASE_SECRET_KEY` و`SUPABASE_ACCESS_TOKEN` و`SUPABASE_DB_PASSWORD` أسرار خادم فقط. يمنع وضعها في متغير يبدأ بـ `NEXT_PUBLIC_` أو طباعتها أو رفع ملفات `.env` إلى Git.

بعد كل بناء، افحص الحزمة:

```powershell
rg "SUPABASE_SECRET_KEY|SUPABASE_ACCESS_TOKEN|SUPABASE_DB_PASSWORD" .next/static
```

يجب ألا تظهر أي قيمة سرية في الناتج.

## طبقات الحماية الإضافية

- رؤوس CSP و`X-Frame-Options` و`nosniff` وسياسة Referrer وPermissions Policy.
- `noindex` و`no-store` للوحات والملفات.
- تحديد معدل طلبات نموذج التواصل العام.
- تحقق Zod عربي قبل الكتابة.
- سجل تدقيق للدخول، وإدارة الحسابات، والوثائق، والتقارير، والعمليات الإدارية الحساسة.
- أرقام الحالات مولدة في PostgreSQL وغير قابلة للتغيير.
- دفعة المتبرع الشهرية منفصلة عن تحويل المبادرة لليتيم، وتتحقق قاعدة البيانات من تطابق المتبرع واليتيم وعلاقة الكفالة والشهر في كل تحويل.
- حذف ملف يتيم كامل يتطلب رقم الحالة ويجري حذف السجلات التابعة داخل معاملة قبل تنظيف الملفات الفعلية.
- لا توجد أدوات تحليلات خارجية في الصفحات المحمية.
- لا تعالج المنصة الدفع ولا تخزن بيانات بطاقات.

## التشغيل الآمن

- استخدم HTTPS فقط في الإنتاج.
- فعّل MFA لحسابات Supabase الإدارية ولوحة cPanel.
- سلّم كلمة المرور المؤقتة للمتبرع عبر قناة مؤسسية آمنة، واطلب تغييرها بعد أول دخول.
- راجع سجل التدقيق ومحاولات الوصول المرفوضة دورياً.
- حدّث Node.js والحزم بعد اختبار البناء والاختبارات.
- احتفظ بنسخ مشفرة من قاعدة البيانات و`public/uploads/orphans` واختبر الاستعادة.

## الاستجابة لحادث

1. أوقف الحساب أو التطبيق المتأثر.
2. دوّر مفاتيح Supabase وأسرار cPanel إذا كان هناك احتمال لتسربها.
3. احتفظ بسجل التدقيق ونسخ الخادم دون طباعة بيانات حساسة إضافية.
4. حدّد الحالات والمتبرعين والملفات المتأثرة.
5. استعد من نسخة سليمة عند الحاجة.
6. وثّق السبب والإصلاح والإشعارات القانونية أو المؤسسية المطلوبة.

أبلغ عن ثغرة عبر قناة المؤسسة الأمنية المعتمدة، ولا ترفق وثائق أو بيانات مستفيدين في البلاغ الأولي.
