كيف تقوم بتأمين تطبيقات React Native؟

Question

Accepted Answer

يتضمن تأمين تطبيقات React Native حماية **البيانات** (التخزين الآمن والإرسال المشفر)، والتعامل الآمن مع **الأسرار والرموز (tokens)**، وتأمين **حزمة JavaScript**، واتباع أفضل الممارسات الأمنية للهواتف المحمولة. الأمان مهم لأن التطبيقات تتعامل مع بيانات المستخدم الحساسة.

## أمان البيانات والبيانات الاعتمادية

```text
✓ SECURE STORAGE for sensitive data — react-native-keychain / expo-secure-store
  (encrypted, keychain/keystore) — NOT AsyncStorage (which is NOT encrypted) for tokens/
  credentials (a common mistake)
✓ HTTPS/TLS for all network traffic; certificate pinning for sensitive apps
✓ Don't HARDCODE secrets/API keys in the JS — the JS BUNDLE can be extracted/inspected
  (anything in the app can be reverse-engineered) → keep real secrets on the SERVER
✓ Secure auth: OAuth, short-lived tokens, secure refresh; biometric auth where appropriate
```

## أمان الكود والمنصة

```text
✓ The JS bundle is shipped with the app → assume it can be READ:
  → don't embed sensitive logic/secrets; sensitive operations belong on the server
  → OBFUSCATE (limited protection); detect tampering/jailbreak/root for high-security apps
✓ Validate inputs; secure deep links (validate params); be careful with WebViews
✓ Keep DEPENDENCIES updated (npm vulnerabilities); audit packages (supply chain risk)
```

## من جانب الخادم والعام

```text
✓ NEVER trust the client → validate and authorize on the SERVER (the client can be
  tampered with — a fundamental principle)
✓ Least privilege; protect APIs (auth, rate limiting); don't leak data in logs
✓ Handle permissions minimally; protect user privacy
```

## لماذا يهم

فهم كيفية تأمين تطبيقات React Native هو معرفة مهمة على مستوى أول لأن **التطبيقات تتعامل مع بيانات حساسة للمستخدم** على أجهزة يمكن اختراقها، لذا الأمان أساسي مع عواقب حقيقية في حالة الإهمال. **أمان البيانات والبيانات الاعتمادية** أمر أساسي: استخدام **التخزين الآمن** (react-native-keychain/expo-secure-store، مشفر) للبيانات الحساسة مثل الرموز — **وليس AsyncStorage** الذي غير مشفر (خطأ شائع وخطير جداً) — استخدام **HTTPS/TLS** لجميع حركة المرور، والأهم **عدم ترميز الأسرار في JavaScript** (لأن **حزمة JS تُرسل مع التطبيق ويمكن استخراجها وفحصها** — يمكن عكس تصميم أي شيء في التطبيق، لذا يجب أن تبقى الأسرار الحقيقية على الخادم).

هذه نقطة أن حزمة JS قابلة للقراءة هي اعتبار أمان حرج خاص بـ React Native. **أمان الكود والمنصة** يعزز هذا: افتراض أن حزمة JS يمكن قراءتها (لذا المنطق والأسرار الحساسة تنتمي إلى الخادم وليس العميل)، والتحقق من المدخلات والروابط العميقة (deep links)، والحذر من WebViews، والحفاظ على تحديث المكتبات (مخاطر سلسلة التوريد npm). **التحقق من جانب الخادم** ضروري: المبدأ الأساسي أن تـ**لا تثق بالعميل** أبداً (الذي يمكن تعديله) ويجب التحقق والترخيص على الخادم — حجر الزاوية في الأمان وذو صلة خاصة بما أن العميل هو تطبيق محمول قابل لعكس التصميم.

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

بما أن تطبيقات React Native تتعامل مع بيانات حساسة على أجهزة قابلة للاختراق (مع كون حزمة JS قابلة للفحص)، وبما أن الأمان السليم (التخزين الآمن وليس AsyncStorage وعدم ترميز الأسرار والتحقق من جانب الخادم و HTTPS) يمنع الثغرات الحقيقية التي يسببها إهماله، فإن فهم كيفية تأمين تطبيقات React Native هو معرفة حرجة أمنية مهمة على مستوى أول — ضروري لحماية بيانات المستخدم وعكس المسؤولية الأمنية المتوقعة للأدوار الأولى ومعالجة مخاطر تطبيقات الهاتف المحمول الحقيقية (خاصة حزمة JS القابلة للقراءة والعميل غير الموثوق به) المتأصلة في تطبيقات React Native.