الأمان في تطبيقات الويب: دروس تعلمتها

الأمان في تطبيقات الويب مش رفاهية — ده ضرورة. وأنا ببني تطبيقات زي طمني وإسمع راديو ونظام الإقبال، اكتشفت إن الثغرات الأمنية مش نظرية، دي حقيقية وممكن تحصل لأي حد. في المقال ده هشارك الدروس اللي تعلمتها بالطريقة الصعبة عشان ماتتعلمهاش بنفس الطريقة.

أول درس كان عن XSS (Cross-Site Scripting). في مشروع بسيط كنت بعمله، كنت بعرض تعليقات المستخدمين بدون ما أعالج النص (sanitize). يوم اكتشفت إن شخص قدر يحط كود JavaScript في التعليق وشغّله على أجهزة المستخدمين التانيين. من يومها وأنا بستخدم DOMPurify لتنظيف أي HTML بتأتي من المستخدم قبل ما أعرضه. كمان React بطبيعته بيحمي من XSS لأنه بيهرب (escape) النصوص تلقائيًا، بس لما بتستخدم dangerouslySetInnerHTML بتفقد الحماية دي.

الدرس التاني كان عن CSRF (Cross-Site Request Forgery). تخيل إنك داخل في طمني ومشارك موقعك، وفجأة تفتح موقع تاني خبيث يبعت طلب لطمني باسمك بدون ماتعرف. الحل كان استخدام CSRF Tokens — كل نموذج بيحتوي على توكن سري يتأكد منه السيرفر. في نظام الإقبال، كل نموذج تسجيل بيحتوي على CSRF Token عشان نتأكد إن الطلب جاي من الموقع نفسه مش من مكان تاني.

أكبر غلطة عملتها كانت مع متغيرات البيئة (.env). في واحد من مشاريعي الأولى، كنت حاطط مفتاح API في الكود نفسه مش في ملف .env. وبالصدفة رفعت الكود على GitHub بالخطأ. خلال ساعات، لقى حد استخدم المفتاح وعمل آلاف الطلبات على حسابي. من يومها وأنا بستخدم .env.local للبيانات الحساسة وبأتأكد إن .gitignore بيستثني الملفات دي. كمان استخدمت Vercel Environment Variables للنشر عشان المفاتيح متكونش في الكود أصلًا.

المصادقة الآمنة في نظام الإقبال كانت تجربة تعليمية مهمة. استخدمت OTP عبر البريد الإلكتروني بدل كلمات السر التقليدية. السبب: كلمات السر ممكن تتخمن ويكون ليها قاموس، بس OTP ليه صلاحية محدودة وبيتغير كل مرة. كمان استخدمت Rate Limiting على إرسال OTP عشان أمنع الـ brute force. كل عنوان IP مش يقدر يطلب أكتر من 5 OTP في الساعة.

Rate Limiting عمومًا درس مهم. في إسمع راديو، لاحظت إن في bots بتحاول تجلب آلاف المحطات في ثواني. أضفت Rate Limiting على كل API Endpoint وده حماي من الـ DDoS ومن الاستخدام المفرط للموارد. استخدمت نمط Sliding Window Rate Limiting اللي بيسمح بـ 100 طلب كل 15 دقيقة لكل مستخدم.

التحقق من المدخلات (Input Validation) مش رفاهية — ده خط الدفاع الأول. في كل تطبيقاتي، بتحقق من كل حاجة بتأتي من المستخدم: النوع، الطول، التنسيق. استخدمت Zod للتحقق من النماذج في Next.js وده وفّر عليّ كتابة Validation يدوي. في نظام الإقبال، بيانات الطالب لازم تتطابق مع أنماط محددة: الإيميل لازم يكون صحيح، الرقم المصري لازم يبدأ بـ 01 ويتكون من 11 رقم.

نصيحة أخيرة ومهمة: الأمان عملية مستمرة مش خطوة واحدة. كل ما تكتشف ثغرة جديدة، أصلحها ووثّقها. اعمل Security Audit دوري لكودك. واستخدم أدوات زي npm audit عشان تكتشف الثغرات في المكتبات اللي بتستخدمها. الثغرات الأمنية مش عيب فيك كمطور — العيب إنك تتجاهلها.