قائمه فحص أمان الموقع التي يحتاجها كل نشاط تجاري في 2026

لو عندك شغل أونلاين وعمرك ما حد سلّمك تشيك ليست حقيقي لأمان المواقع بإصدار 2026، يبقى المقال ده هو اللي كنت بتدوّر عليه. أنا خالد أحمد، مطوّر Full Stack سينيور مقيم في القاهرة، وعلى مدار آخر خمس سنين سلّمت أكتر من 25 مشروع إنتاجي لعملاء في مصر والسعودية والإمارات وبريطانيا وسويسرا وفرنسا وألمانيا والكويت. كل حادثة اختراق أمني نضّفتها لعميل كانت سببها بند ناقص من تشيك ليست أساسية، مش ثغرة zero-day على طريقة أفلام هوليوود. الدليل ده بيديك ثلاثة وعشرين ضابط أمني، مقسّمين على سبعة مجالات، يصدّوا حوالي 95% من الهجمات الحقيقية. سلّمه لمطوّرك، استخدمه عشان تقيّم مزوّد خدمة، أو خليه أساسك عشان تقرر هل محتاج مراجعة أمنية احترافية ولا لأ.

1. إيه اللي بتغطيه فعلاً تشيك ليست أمان المواقع في 2026

تشيك ليست أمان الموقع مش بروشور تسويقي. ده مستند شغل، قائمة بضوابط قابلة للقياس والتحقق، إما موجودة على موقعك أو لأ. لما بعمل مراجعة مدفوعة، بفتح نفس التشيك ليست دي على شاشة وكود العميل على الشاشة التانية. بند بند، بكتب "ناجح" أو "فاشل" أو "جزئي". المخرج ده بيبقى هو التقرير.

خط الأساس اللي بستخدمه في 2026 بيغطي سبعة مجالات: المصادقة وإدارة الجلسات، التحقق من المدخلات، تشفير النقل والتخزين، HTTP security headers، إدارة الاعتماديات والترقيعات، التسجيل المنظّم والمراقبة، وخطة استجابة مكتوبة للحوادث. كل مجال فيه من ثلاثة لستة ضوابط ملموسة. القائمة الكاملة 23 بند، وهنمشي عليهم واحد واحد في المقال ده بنفس الإعدادات اللي بنزّلها في الإنتاج.

إيه اللي التشيك ليست دي مش هي: مش بديل عن threat modeling لتطبيق بنكي، مش بديل عن تقييم PCI DSS 4.0 لو بتاخد دفعات كروت مباشرة، ومش درع سحري ضد مهاجم بمستوى دولة قرر يستهدفك إنت بالذات. هي الأساس. من غيرها مفيش حاجة تانية تنفع. ومعاها، إنت بقيت مش الفريسة السهلة اللي السكانرات الأوتوماتيكية بتلتقطها كل اتناشر ثانية.

2. ليه 95% من الاختراقات بسبب أساسيات ناقصة، مش بسبب zero-days

عايز أقتل أسطورة قبل ما نكمّل. معظم أصحاب الأعمال بيتخيلوا الاختراق إن في ناس لابسة هودي بيكتبوا بسرعة عشان يكسروا دفاعات متطورة. الحقيقة مملة جدًا. كل تقرير اختراق علني قريته في آخر تلات سنين، من Verizon DBIR لـ IBM Cost of a Data Breach، بيحكي نفس القصة. المهاجم سكان الإنترنت العام، لقى سيرفر بمكتبة مش متحدّثة أو باسوورد admin افتراضي، ودخل من الباب الأمامي.

دي اللي بشوفها في المراجعات الحقيقية، بترتيب تقريبي حسب التكرار:

• اعتماديات قديمة فيها CVEs معروفة وأكواد استغلال منشورة.
• مفيش rate limiting على تسجيل الدخول أو إعادة تعيين الباسوورد أو نماذج التواصل.
• كلمات سر مُهشّرة بـ MD5 أو SHA1، أو، ومش بهزّر، مخزّنة كنص عادي.
• لوحات أدمن مكشوفة على روابط متوقعة من غير IP allowlist ومن غير 2FA.
• رفع ملفات بيقبل أي امتداد ويخزّن جوه web root.
• بيانات اعتماد قاعدة البيانات اتعملها commit في ريبو عام لأن حد نسي ملف .env.
• HTTPS متظبط بس من غير HSTS، فهجوم downgrade يبقى تافه.
• مفيش logs، أو الـ logs بس على السيرفر المُخترَق نفسه، والمهاجم بيمسحها أول حاجة.

ولا حاجة من دي محتاجة zone-day. محتاجة سكريبت Python وعشر دقائق. قائمة OWASP Top 10 لسنة 2025 بتقرأ زي 2017 تقريبًا لأن نفس الأخطاء بتتكرر. اتباع تشيك ليست أمان المواقع 2026 معناه إنك بطّلت تعمل الأخطاء دي.

لو مطوّرك قالك "الأمان معقّد ومش هينفع أشرحه لك"، فصّله. الأساسيات مش معقّدة. هي مملة، والمملّ هو اللي بيتساب لما المواعيد تضيق. شغل المهندس السينيور إنه يخلي المملّ مش قابل للتفاوض.

3. المشهد التهديدي في 2026: المهاجمون بيستهدفوا إيه النهارده

المشهد التهديدي اتغيّر بثلاث طرق جوهرية من 2023، وتشيك ليستك لازم تعكس ده.

أولاً، credential stuffing بقى الهجوم المهيمن على المواقع الموجّهة للمستهلكين. المهاجمون بيشتروا بلايين أزواج إيميل-باسوورد مسرّبة على تليجرام بأقل من خمسين دولار، ويعيدوا تشغيلها على كل نموذج تسجيل دخول على الإنترنت باستخدام شبكات بروكسي سكنية. لو عندك مفيش rate limiting وكشف بوتات، كل حساب على موقعك بباسوورد متكررة هو فعلاً مُخترَق. إنت بس لسه مش عارف.

ثانيًا، هجمات سلاسل التوريد بقت روتينية. المهاجم مش محتاج يخترق كودك، هو بيخترق باكدج إنت معتمد عليها، وأول deploy جديد بينزّل البرمجية الخبيثة بتاعته. ثغرة xz-utils backdoor في 2024 والسيل المستمر من باكدجات npm الخبيثة بيثبتوا إن ده مش كلام نظري. فحص الاعتماديات وتثبيت الإصدارات بقى إلزامي.

ثالثًا، الهجمات المدعومة بالذكاء الاصطناعي قلّلت حاجز الاستغلال المخصّص. زمان المهاجم كان محتاج مهارة يدوية يربط ثغرات في exploit شغّال، دلوقتي نماذج اللغة الكبيرة بتولّد أكواد proof-of-concept شغّالة من وصف CVE في أقل من دقيقة. النافذة بين الكشف والاستغلال الجماعي انهارت من أسابيع لساعات. لو إيقاع الترقيع بتاعك "شهري لما يبقى عندنا وقت"، فإنت مكشوف لأسابيع كل شهر.

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

4. إزاي تستخدم التشيك ليست دي (مراجعة ذاتية مقابل مراجعة احترافية)

في طريقتين تستخدم بيهم المستند ده. الأولى كمراجعة ذاتية. اطبعها، افتح كودك، وتشيك كل بند. لو قدرت تجاوب "أيوه، ودي مكان تنفيذه" على كل الـ 23، فإنت في الـ 5% الأعلى من المواقع اللي بشوفها. لو قدرت تقول "أيوه" لـ 15، إنت متوسط. أقل من 15، عندك شغل عاجل.

الطريقة التانية إنك تستخدمها كموجز لمحترف. لما تستأجر حد لمراجعة تشيك ليست أمان موقع، سلّمه المقال ده واطلب منه يملا الحكم وخطوات المعالجة. لو رفض وقال "الأمان مش بيشتغل بالتشيك ليست"، امشي. الأمان فعلاً بيشتغل بالتشيك ليست. كل جهة شهادات في العالم، ISO 27001 وSOC 2 وPCI DSS، مبنية على تشيك ليستات. اللي محتاج اجتهاد هو ترتيب الأولويات وتحليل التهديدات، مش هل الكوكيز عندك بفلاج Secure ولا لأ.

للمراجعة الذاتية، حدّد ميزانية حوالي 8 ساعات لموقع صغير، 3 أيام لتطبيق SaaS عادي، وأسبوع كامل لمنصة تجارة إلكترونية مع تكامل دفع. للمراجعة الاحترافية، توقّع تدفع بين 1,500 و8,000 دولار حسب النطاق. قارن ده بـ دليلي عن تكاليف مشاريع المواقع هتلاقي الأمان من أعلى بنود الميزانية من حيث العائد على الاستثمار.

5. المصادقة وإدارة الجلسات: التهشير و2FA وفلاجات الكوكيز

المصادقة هي مكان بداية معظم الاختراقات. ظبّطها وهتقضي على فئة كاملة من الهجمات. دول أول ست ضوابط في تشيك ليست أمان المواقع 2026.

الضابط 1: هشّر الباسوورد بـ bcrypt أو argon2

لو تطبيقك بيستخدم MD5 أو SHA1 أو SHA256 أو أي هاش بدون salt، عندك حالة طوارئ. الهاشات دي مصمّمة تكون سريعة، وده عكس اللي إنت عايزه للباسووردات بالظبط. المهاجمون الحديثون بيكسروا بلايين هاشات MD5 في الثانية على جهاز GPU عادي للمستهلك.

استخدم bcrypt (بمعامل تكلفة 12 أو أعلى في 2026) أو argon2id (توصية OWASP). في Laravel، ده الافتراضي، لكن شفت مطوّرين بيستبدلوه بتطبيقات "أداء" مخصّصة. متعملش كده. نقاش bcrypt مقابل argon2 محسوم تقريبًا: argon2id أصعب من ناحية الذاكرة وهو التوصية الحديثة، بس bcrypt بتكلفة 12+ لسه مقبول.

// Laravel - already correct by default
use Illuminate\Support\Facades\Hash;

// Verify cost factor is 12+ in config/hashing.php
'bcrypt' => [
    'rounds' => env('BCRYPT_ROUNDS', 12),
],

// Or switch to argon2id
'driver' => 'argon2id',
'argon' => [
    'memory' => 65536,
    'threads' => 1,
    'time' => 4,
],

الضابط 2: ضع حد لمعدّل طلبات تسجيل الدخول

خمس محاولات في الدقيقة لكل IP، مع backoff تدريجي على الفشل المستمر. خمس محاولات في الساعة لكل اسم مستخدم بصرف النظر عن الـ IP، عشان تهزم الهجمات الموزّعة. اقفل الحساب مؤقتًا بعد عشرين محاولة فاشلة وابعت للمستخدم إيميل. هنغطي rate limiting بتفصيل أكتر في الجزء التالي.

الضابط 3: قدّم 2FA، وافرضها على الأدمن

كلمات المرور لمرة واحدة المعتمدة على الوقت (TOTP) عبر تطبيقات زي Authy أو 1Password هي الحد الأدنى. مفاتيح WebAuthn passkeys أحسن وبتاخد دعم متزايد. خلّي 2FA اختيارية للمستخدم النهائي (متضيفش احتكاك للتسجيل)، بس إلزامية لأي حساب فيه صلاحيات إدارية أو قدرة تصدير بيانات أو وصول لضوابط مالية. اختبر مسار الاستعادة، معظم اختراقات 2FA بتحصل لأن عملية الاستعادة أضعف من الباب الأمامي.

الضابط 4: فلاجات الكوكيز اللي بتمنع الهجمات الأساسية

كوكيز الجلسة لازم تتعمل بثلاث فلاجات: HttpOnly (بيمنع سرقة الجافاسكريبت عبر XSS)، Secure (بيمنع النقل على HTTP عادي)، وSameSite=Lax أو Strict (بيمنع CSRF عبر الطلبات بين المواقع). خاصية كوكي SameSite لوحدها بتقفل الباب على فئة ضخمة من الهجمات. في Laravel، ظبّط دي في config/session.php:

'http_only' => true,
'secure' => env('SESSION_SECURE_COOKIE', true),
'same_site' => 'lax',
'partitioned' => false, // Set true if embedded in iframes

الضابط 5: ألغ صلاحية الجلسات عند تغيير الباسوورد والخروج

لما المستخدم يغيّر الباسوورد، كل جلسة موجودة للمستخدم ده لازم تتنهي. لما يعمل لوج آوت، توكن الجلسة لازم يتمسح من السيرفر، مش بس من العميل. راجعت مواقع كان "تسجيل الخروج" فيها بيمسح كوكي بس، رقم الجلسة لسه صالح وممكن يُعاد استخدامه إلى ما لا نهاية. session fixation هجوم حقيقي والضابط ده بيمنعه.

الضابط 6: توكنات إعادة تعيين الباسوورد تنتهي صلاحيتها في 30 دقيقة

توكنات إعادة التعيين هي بيانات اعتماد حامِل. أي حد عنده التوكن يقدر يستولي على الحساب. خلّيها لاستخدام واحد، انتهي صلاحيتها في 30 دقيقة كحد أقصى، وألغها بمجرد ما تتغيّر كلمة السر. متحطّش التوكن في URL بيتسجّل في analytics، استخدم نموذج POST على صفحة الهبوط لو ممكن.

6. Rate Limiting والدفاع ضد credential stuffing

Credential stuffing هو الهجوم بأعلى حجم على الإنترنت النهارده. المهاجمون بيشغّلوا قوائم بيانات اعتماد مسرّبة على نموذج تسجيل الدخول بتاعك، أمل في نسبة من مستخدمينك بتعيد استخدام نفس الباسوورد. من غير rate limiting، هينجحوا.

Rate limiting لازم يتطبق على تلات طبقات:

1. لكل IP على الحافة (CDN أو reverse proxy أو قواعد WAF): 60 طلب في الدقيقة لروابط تسجيل الدخول. Cloudflare وAWS WAF وBunnyCDN كلهم بيدعموا ده بكام كليكة.
2. لكل اسم مستخدم في طبقة التطبيق: 5 محاولات فاشلة لكل اسم مستخدم كل 15 دقيقة، بصرف النظر عن مصدر الـ IP. ده اللي بيهزم credential stuffing الموزّع من شبكات البوت.
3. backoff أُسّي لكل حساب: بعد 20 محاولة فاشلة، اطلب تأكيد إيميل أو فتح من الأدمن.

في Laravel، الـ throttle middleware بيتعامل مع كل IP. لكل اسم مستخدم، محتاج منطق مخصّص:

public function login(Request $request)
{
    $key = 'login:' . Str::lower($request->email);

    if (RateLimiter::tooManyAttempts($key, 5)) {
        $seconds = RateLimiter::availableIn($key);
        return back()->withErrors([
            'email' => "Too many attempts. Try again in {$seconds}s.",
        ]);
    }

    if (!Auth::attempt($request->only('email', 'password'))) {
        RateLimiter::hit($key, 900); // 15 minutes
        return back()->withErrors(['email' => 'Invalid credentials.']);
    }

    RateLimiter::clear($key);
    return redirect()->intended('/dashboard');
}

اقرنه بكشف البوتات. Cloudflare Turnstile مجاني ومحافظ على الخصوصية وفعّال ضد معظم الأدوات الأوتوماتيكية. للحسابات عالية القيمة، فكّر في بصمة الجهاز والمصادقة المبنية على المخاطر، اعمل تحدّي لأي تسجيل دخول من جهاز جديد أو موقع غير مألوف.

7. التحقق من المدخلات، SQL Injection، XSS، ومنع CSRF

هجمات الحقن الكلاسيكية موجودة في قائمة OWASP Top 10 من 2003. ولسه شغّالة لأن المطوّرين لسه بيدمجوا strings في الاستعلامات وبيحطّوا مدخلات المستخدم مباشرة في HTML. ضوابط تشيك ليست أمان تطبيقات الويب هنا مش قابلة للتفاوض.

الضابط 7: تحقّق من كل مدخلات المستخدم من جانب السيرفر

التحقق من جانب العميل ميزة تجربة مستخدم. بيقول للمستخدم "الإيميل ده شكله غلط" من غير رحلة للسيرفر. ده مش أمان. أي حد يقدر يطفي الجافاسكريبت أو يبعت طلبات خام بـ curl. كل مدخل، باراميترات الاستعلام، حقول النماذج، أجسام JSON، الهيدرز، أسماء الملفات، لازم يتم التحقق منه على السيرفر قبل الاستخدام.

في Laravel، استخدم Form Request classes بقواعد صريحة. في Node.js/Express، استخدم Zod أو Joi. متثقش أبدًا في شكل أو نوع أو محتوى المدخل.

الضابط 8: امنع SQL injection بالاستعلامات المُعَلْمَنة

استخدم الـ ORM. Eloquent، Prisma، SQLAlchemy، ActiveRecord كلهم بيستخدموا استعلامات مُعَلْمَنة افتراضيًا. لو لازم تنزل لـ SQL خام، استخدم placeholders، مش string interpolation. الصح والغلط:

// WRONG - SQL injection waiting to happen
$users = DB::select("SELECT * FROM users WHERE email = '" . $email . "'");

// RIGHT - parameterized
$users = DB::select("SELECT * FROM users WHERE email = ?", [$email]);

// BEST - use the ORM
$user = User::where('email', $email)->first();

لمزيد من العمق في أنماط الوصول الآمن للبيانات، شوف دليلي عن تصميم قواعد بيانات تطبيقات الويب.

الضابط 9: امنع XSS بترميز إخراج صحيح

Cross-site scripting بتحصل لما مدخلات المستخدم تتعرض في HTML بدون escape. صياغة {{ }} في Blade بتعمل auto-escape. JSX في React بيعمل auto-escape. قوالب Vue بتعمل auto-escape. الخطر هو فتحات الهروب: {!! !!}، dangerouslySetInnerHTML، v-html. راجع كل استخدام لدول. لو بتقبل HTML غني من المستخدمين (تعليقات مدونة، بايو بروفايل)، نظّفه على السيرفر بمكتبة مجرّبة زي HTMLPurifier أو DOMPurify قبل التخزين.

الضابط 10: توكنات CSRF على كل طلب بيغيّر حالة

أي POST أو PUT أو PATCH أو DELETE بيغيّر حالة السيرفر محتاج توكن CSRF. Laravel بيتضمّن ده افتراضيًا عبر توجيه @csrf وVerifyCsrfToken middleware. تطبيقات الـ SPA عادة بتستخدم توكن في هيدر. تدوير توكن CSRF عند تسجيل الدخول ورفع الصلاحيات بيمنع fixation. كوكيز SameSite=Lax بتقدّم طبقة دفاع ثانية، بس التوكنات لسه مطلوبة للعمليات الحساسة.

8. التعامل الآمن مع رفع الملفات والتخزين خارج web root

الضابط 11: رفع الملفات صح

رفع الملفات هو أخطر مدخل من المستخدم. الملف الخبيث ممكن يكون PHP shell، أو SVG فيه جافاسكريبت مدمج، أو polyglot صالح كصورة وكسكريبت في نفس الوقت، أو zip bomb بيستنزف القرص. الضابط هنا متعدد الطبقات.

أولاً، تحقّق من نوع MIME ومحتوى الملف الفعلي، مش الامتداد بس. ملف اسمه cute-puppy.jpg ممكن يحتوي على أي حاجة. استخدم مكتبة على السيرفر بتفحص الـ magic bytes (هيدرز الملف).

ثانيًا، افرض حدود حجم صارمة، لكل ملف ولكل طلب. حد 10 ميجابايت للصور بيمنع معظم هجمات الـ denial-of-service على القرص.

ثالثًا، خزّن الملفات المرفوعة خارج web root. ماتخلّيش ملف من المستخدم يتم تقديمه مباشرة من ويب سيرفر. مرّرهم عبر كنترولر تطبيق بيفرض التفويض ويعيد ترميزهم لو أمكن.

رابعًا، أعد تسمية الملفات لـ UUIDs عشوائية. أسماء الملفات الأصلية هي ناقل هجوم، directory traversal وأحرف خاصة وأسماء قابلة للتنفيذ. خزّن الاسم الأصلي بشكل منفصل لو محتاج تعرضه.

// Laravel - safer upload pattern
$request->validate([
    'avatar' => 'required|image|mimes:jpg,png,webp|max:2048',
]);

$path = $request->file('avatar')->store(
    'avatars',          // disk path outside web root
    's3'                // or 'local' with private disk
);

// Serve via controller, not direct URL
Route::get('/avatar/{user}', [AvatarController::class, 'show'])
    ->middleware('auth');

لمواقع التجارة الإلكترونية اللي بتتعامل مع صور المنتجات ورفع العملاء، دليلي لتطوير مواقع التجارة الإلكترونية بيتعمّق أكتر في خطوط أنابيب الأصول.

9. أمان النقل: HTTPS وHSTS Preload وإعدادات TLS 1.3

الضابط 12: HTTPS في كل مكان مع HSTS preload

إحنا في 2026. مفيش عذر لموقع بدون HTTPS، في أي مكان، أبدًا. شهادات مجانية من Let's Encrypt أو Cloudflare بتخلي ده إعداد بكليكة واحدة مع معظم المستضيفين. شوف دليلي لاختيار استضافة الويب في 2026 لمعرفة المزوّدين اللي بيظبّطوا ده افتراضيًا.

بس HTTPS لوحده مش كفاية. من غير HSTS (HTTP Strict Transport Security)، مهاجم على نفس شبكة الـ Wi-Fi يقدر ينزّل أول اتصال لـ HTTP ويسرق الجلسة. هيدر HSTS بيقول للمتصفح "استخدم HTTPS دايمًا للدومين ده للسنة الجاية". قدّم دومينك لقائمة HSTS preload (hstspreload.org) والمتصفح هيرفض HTTP حتى في أول زيارة على الإطلاق.

# Nginx - secure transport configuration
server {
    listen 443 ssl http2;
    server_name example.com;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
    ssl_prefer_server_ciphers off;
    ssl_session_cache shared:SSL:10m;
    ssl_session_tickets off;

    add_header Strict-Transport-Security
        "max-age=63072000; includeSubDomains; preload" always;
}

الضابط 13: TLS 1.2 كحد أدنى، TLS 1.3 مُفضّل

عطّل TLS 1.0 و1.1، دول قديمين وعندهم نقاط ضعف معروفة. TLS 1.3 أسرع (مصافحة TLS 1.3 رحلة واحدة بدل اتنين) وبيشيل الـ ciphers الضعيفة بالكامل. اختبر إعدادك على ssllabs.com/ssltest. أي حاجة أقل من تقدير A بتعتبر ملاحظة في المراجعة.

10. التشفير في حالة السكون، إدارة الأسرار، والنسخ الاحتياطية المختبرة

الضابط 14: شفّر البيانات الحساسة في حالة السكون

المعلومات الشخصية القابلة للتعريف وبيانات الدفع والسجلات الصحية وتوكنات المصادقة لازم تتشفّر في قاعدة البيانات. encrypted casts في Laravel بتخلي ده بسيط:

protected $casts = [
    'tax_id' => 'encrypted',
    'bank_account' => 'encrypted',
    'medical_notes' => 'encrypted:object',
];

على طبقة البنية التحتية، استخدم EBS volumes مشفّرة على AWS، أقراص مشفّرة على Hostinger أو DigitalOcean، وتأكّد إن النسخ الاحتياطية لقاعدة البيانات مشفّرة كمان. التشفير في حالة السكون مش بيدافع ضد تطبيق مُخترَق، بس بيدافع ضد نسخة احتياطية مسروقة، أو صورة قرص مسرّبة، أو قرص اتشال.

الضابط 15: الأسرار في متغيرات البيئة، أبدًا في الكود

باسووردات قاعدة البيانات ومفاتيح API وأسرار التوقيع وبيانات اعتماد OAuth أبدًا متخصّش الكود المصدري. استخدم متغيرات البيئة (ملفات .env) محليًا وحل إدارة أسرار مناسب في الإنتاج: AWS Secrets Manager أو HashiCorp Vault أو Doppler أو حتى ملفات env مشفّرة عبر SOPS.

ضيف .env لـ .gitignore. راجع تاريخ git بتاعك للأسرار اللي اتعملها commit بالغلط بأدوات زي git-secrets أو trufflehog. لو لقيت تسريب، دوّر بيانات الاعتماد، المهاجم يبقى نسخ الريبو فعلاً.

الضابط 16: نسخ احتياطية مشفّرة ومختبرة

النسخ الاحتياطية اللي ما اتسترجعتش أبدًا مش موجودة. كل ربع سنة، اعمل تدريب استعادة كاملة لبيئة staging. تحقّق إن البيانات سليمة، التطبيق بيشتغل، وتقدر تسجّل دخول. النسخ الاحتياطية لازم تكون مشفّرة، مخزّنة خارج الموقع (منطقة سحابة مختلفة أو مزوّد مختلف)، ومحتفظ بيها حسب سياسة موثّقة. قاعدة الثلاثة-اتنين-واحد: ثلاث نسخ، نوعين وسائط، واحدة خارج الموقع.

11. HTTP Security Headers: CSP وX-Frame-Options وReferrer-Policy وCOOP/COEP

HTTP security headers هي أرخص دفاع بأعلى قيمة تقدر تضيفه. متكلّفش حاجة، بتاخد ساعة عشان تظبّط بشكل صحيح، وبتسد فئات كاملة من الهجمات. دول ضوابط 17 لحد 20، تشيك ليست HTTP security headers.

الضابط 17: Content-Security-Policy

CSP هي أقوى هيدر منفرد. بتقول للمتصفح إيه مصادر السكريبتات والأنماط والصور والإطارات المسموح بيها. CSP مظبوط بيمنع معظم XSS حتى لو كودك فيه باج. المقايضة إن CSP صعب يتظبّط للمواقع اللي عندها widgets طرف ثالث كتير.

ابدأ في وضع report-only لأسبوع، صلّح الانتهاكات، وبعدين افرض. توجيهات Content-Security-Policy الأساسية:

Content-Security-Policy:
  default-src 'self';
  script-src 'self' https://cdn.example.com;
  style-src 'self' 'unsafe-inline' https://fonts.googleapis.com;
  img-src 'self' data: https:;
  font-src 'self' https://fonts.gstatic.com;
  connect-src 'self' https://api.example.com;
  frame-ancestors 'none';
  base-uri 'self';
  form-action 'self';
  upgrade-insecure-requests;

الضابط 18: X-Content-Type-Options: nosniff

بيمنع المتصفحات من تخمين نوع MIME للاستجابة. ده بيوقف هجمات يرفع فيها المهاجم ملف بامتداد مضلّل عشان يخلي المتصفح ينفذه.

الضابط 19: X-Frame-Options: SAMEORIGIN

بيمنع موقعك من إنه يتدمج في iframe على صفحة خبيثة (clickjacking). المعادل الحديث هو توجيه frame-ancestors في CSP، ظبّط الاتنين للتوافق مع الإصدارات القديمة.

الضابط 20: Referrer-Policy: strict-origin-when-cross-origin

بيمنع تسريب الـ URL الكامل (اللي ممكن يحتوي توكنات أو بيانات مستخدم) لمواقع طرف ثالث. ضيف Permissions-Policy وهيدرز COOP/COEP لعزل إضافي، خصوصًا لو موقعك بيعالج بيانات حساسة:

Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()
Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN

اختبر إعدادات الهيدرز على securityheaders.com. اهدف لتقدير A+.

12. ترقيع الاعتماديات بـ Dependabot أو Renovate

الضابط 21: تحديث الاعتماديات شهريًا، بأتمتة

أكبر مصدر منفرد للاختراقات اللي بشوفه في المراجعات الحقيقية هو الاعتماديات القديمة بثغرات CVE معروفة. التحديثات اليدوية مبتحصلش. الحل هو الأتمتة.

فعّل تنبيهات Dependabot على GitHub لكل ريبو، مجاني وبياخد 30 ثانية. الأحسن، ظبّط Renovate bot أو Dependabot يفتح pull requests أوتوماتيكيًا لما يكون في تحديثات. جمّع تحديثات minor وpatch عشان متراجعش 20 PR في الأسبوع.

# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: "composer"
    directory: "/"
    schedule:
      interval: "weekly"
    groups:
      laravel:
        patterns: ["laravel/*", "illuminate/*"]
      dev-dependencies:
        dependency-type: "development"
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    open-pull-requests-limit: 10

شغّل composer audit وnpm audit في CI على كل push وافشل الـ build على ثغرات عالية أو حرجة. اشترك في نشرات الأمان للأطر اللي بتستخدمها، Laravel وNext.js وWordPress كلهم بينشروا CVEs.

مخاطر هجمات سلسلة التوريد بتتعدى الـ CVEs المعروفة. ثبّت الإصدارات بالضبط لو أمكن، راجع اللي بتنزّله (خصوصًا في npm، المشروع المتوسط بيسحب 1,000+ اعتمادية متعدية)، وفكّر في أدوات زي Socket.dev اللي بتعلّم على سلوك باكدج مشبوه في الوقت الفعلي.

13. التسجيل المنظّم، الشحن خارج الجهاز، وخطة الاستجابة للحوادث

الضابط 22: اللوجز منظّمة ومشحونة خارج الجهاز

لو اللوجز بتاعتك الوحيدة على السيرفر المُخترَق، فمالكش لوجز. أول حاجة المهاجم الكفء بيعملها هي إنه يمسح اللوجز المحلية عشان يخفي آثاره. اشحن اللوجز لنظام منفصل في الوقت الفعلي: Logtail أو Datadog أو ELK stack أو حتى syslog server بسيط في حساب سحابي مختلف.

نظّم اللوجز بصيغة JSON، مش نص عادي. ضمّن request ID وuser ID وIP وuser agent والإجراء. إنت في المستقبل، بعد ثلاث أيام من الحادثة الساعة 2 صباحًا، هتبقى ممتن.

// Laravel - structured logging
use Illuminate\Support\Facades\Log;

Log::withContext([
    'request_id' => (string) Str::uuid(),
    'user_id' => auth()->id(),
    'ip' => $request->ip(),
]);

Log::info('payment.processed', [
    'amount' => $payment->amount,
    'currency' => $payment->currency,
    'gateway' => 'stripe',
]);

سجّل الأحداث المتعلّقة بالأمان صراحة: نجاح وفشل تسجيل الدخول، تغييرات الباسوورد، تسجيل وإزالة 2FA، إجراءات الأدمن، تغييرات الأدوار، التصديرات، وأي أخطاء 4xx/5xx. احتفظ بـ 90 يوم على الأقل. الأنظمة الامتثالية غالبًا بتتطلب أطول (PCI DSS 4.0 بيتطلب 12 شهر، مع 3 متاحة فورًا).

الضابط 23: خطة استجابة للحوادث، مكتوبة قبل ما تحتاجها

خطة الاستجابة للحوادث بتجاوب على أربع أسئلة مقدمًا: مين بنتصل بيه؟ نعمل إيه الأول؟ نقول إيه للعملاء؟ نقول إيه للجهات الرقابية؟

الخطة لازم تكون صفحة واحدة، متاحة أوفلاين (لأن الويكي ممكن يكون واقع)، ومختبرة في تمرين tabletop مرة في السنة. لازم تتضمّن:

• أسماء وأرقام تواصل 24/7 لقائد الحادثة والقائد التقني والمستشار القانوني وPR.
• إجراء أخذ النظام المتأثر أوفلاين من غير ما تضيع البيانات الجنائية.
• بيانات تواصل مزوّد الاستضافة ومعالج الدفع والمورّدين الأساسيين.
• قالب مسبق لإشعار الاختراق (إشعار اختراق بيانات GDPR عنده ساعة 72 ساعة، إنت مش عايز تكتب الإيميل لأول مرة وقت الحادثة).
• معايير إمتى تتصل بإنفاذ القانون وأي جهة.
• ترتيب جمع الأدلة: dump للذاكرة، صورة قرص، لوجز، التقاط شبكة.

لو معندكش retainer أمني مع شركة، حدّد واحدة مقدمًا. الاتصال بمستجيب حوادث لأول مرة وقت اختراق نشط هو أغلى طريقة تستأجر بيها أي حد.

14. أخطاء أمان المواقع الشائعة اللي بلاقيها في كل مراجعة

بعد ما شغّلت تشيك ليست أمان المواقع على عشرات المواقع في سبع دول، بتظهر أنماط معيّنة. دي الأخطاء اللي بلاقيها في كل مراجعة عمليًا، بصرف النظر عن حجم الشركة أو الصناعة.

لوحة أدمن على /admin بدون IP allowlist. انقلها لمسار مش متوقع وقيّد الوصول لـ IPs معروفة. لو فريقك ريموت، استخدم VPN أو خدمة زي Cloudflare Access.

وضع debug مفعّل في الإنتاج. APP_DEBUG=true في Laravel بيكشف stack traces كاملة بما فيها بيانات اعتماد قاعدة البيانات. بناء التطوير في Next.js بيسرّب source maps. WP_DEBUG_DISPLAY في WordPress بيعرض الاستعلامات. راجع تشيك ليست الإنتاج لكل إطار.

بيانات اعتماد افتراضية في أي مكان. Admin/admin على قاعدة بيانات الـ staging. اسم المستخدم الافتراضي لكاميرا IoT. الباسوورد الافتراضي لـ Grafana. دوّر كل حاجة بتيجي بافتراضي.

صفحات أخطاء مفصّلة. صفحة "Whoops" أو stack trace بتقول للمهاجم الإطار بتاعك وإصداره وغالبًا مسار الملف لكودك. اعرض صفحة خطأ عامة للمستخدمين وسجّل التفاصيل داخليًا.

إضافات CMS قديمة. WordPress هو الأسوأ. بشوف مواقع شغّالة بإصدارات plugins فيها استغلالات علنية اتعمل لها patch من ثلاث سنين. لو ماتقدرش أو مش هتحدّث، غيّر المنصة. مقارنتي بين WordPress وLaravel بتغطي إمتى كل واحد منهم منطقي.

CORS مظبوط بـ Allow-Origin: * مع credentials مفعّلة. ده بيكسر سياسة same-origin بالكامل وبيخلي أي موقع يقرأ استجابات مُصادَق عليها. حدّد origins بالضبط.

JWT بثغرة alg=none. ثبّت الخوارزمية على السيرفر دايمًا، متثقش أبدًا في الهيدر. ومتحطّش بيانات حساسة في حمولة JWT، دي base64 مش مشفّرة.

S3 buckets مظبوطة كعامة. سوء التكوين الكلاسيكي لـ AWS. استخدم IAM وsigned URLs وBlock Public Access على مستوى الحساب.

15. ملاحظات خاصة بكل تقنية: Laravel وNext.js وWordPress وShopify

تشيك ليست أمان Laravel

Laravel بيشحن بإعدادات افتراضية قوية، بس دي اللي تتأكد منها:

• APP_DEBUG=false وAPP_ENV=production في .env.
• APP_KEY مظبوط لقيمة عشوائية 32 بايت. متعملش commit أبدًا.
• config/session.php عنده فلاجات كوكي آمنة زي ما هو موضح فوق.
• CSRF middleware نشط على كل routes الويب (افتراضي).
• استخدم Form Request validation، مش $request->validate() inline في كل مكان.
• علاقات Eloquent وسياسات تفويض لكل موديل قابل للاستعلام.
• شغّل php artisan route:list وراجع كل route عام، خصوصًا أي حاجة موسومة بـ 'api' بتتخطى مصادقة الجلسة.
• استخدم middleware throttle على تسجيل الدخول والتسجيل وإعادة تعيين الباسوورد وأي endpoint مكلّف.

تشيك ليست أمان Next.js

Next.js 14+ مع App Router عنده غرائبه:

• Server actions محتاجة فحوصات تفويض صريحة، دي endpoints POST عامة بصرف النظر عن مكان استيرادها.
• متحطّش أبدًا أسرار في client components أو متغيرات NEXT_PUBLIC_.
• ظبّط middleware.ts للهيدرز وفحوصات المصادقة على الحافة.
• ظبّط دالة headers() في next.config.js لتضيف CSP وHSTS.
• لـ API routes، تحقّق من المدخلات بـ Zod وحدّ معدل بـ Upstash.

لو بتعمل تحسين لإنتاج Next.js، شوف دليلي لتحسين أداء Next.js، كتير من إعدادات الأداء لها تبعات أمنية.

تشيك ليست أمان WordPress

WordPress هو المنصة الأكثر هجومًا على الإنترنت. الحد الأدنى الإلزامي:

• استخدم استضافة مُدارة (Kinsta أو WP Engine أو Pressable) بتتعامل مع الترقيع.
• عطّل تعديل الملفات في wp-config.php: define('DISALLOW_FILE_EDIT', true);
• حدّ محاولات تسجيل الدخول بـ Wordfence أو Limit Login Attempts Reloaded.
• استخدم 2FA لكل أدمن (Wordfence فيه 2FA مجاني دلوقتي).
• إخفاء /wp-admin خلف slug صعب التخمين أو IP allowlist.
• شيل الثيمات والإضافات غير المستخدمة، دي سطح هجوم حتى لو معطّلة.
• بادئة قاعدة البيانات حاجة غير wp_.
• خلّي عدد الإضافات أقل من 15. كل إضافة هي CVE محتملة.

تشيك ليست أمان مواقع التجارة الإلكترونية

لو بتاخد دفعات، الحد أعلى. PCI DSS 4.0 ينطبق لحظة لمسك بيانات كروت. أبسط طريق هو إنك ماتلمسش بيانات كروت خام، استخدم Stripe Checkout أو Stripe Elements أو حقول PayPal المستضافة عشان بيانات الكارت تروح مباشرة من متصفح المستخدم للمعالج. تنزل من PCI DSS Level 1 (نطاق ضخم) لـ SAQ-A (استبيان قصير).

أبعد من ده، مواقع التجارة الإلكترونية محتاجة تدافع ضد بوتات السكالبر وbrute-force للكوبونات والاستيلاء على الحسابات (المربوطة بطرق دفع محفوظة) واحتيال الاسترداد. ضيف فحوصات سرعة على الطلبات، تحقق العنوان، و3D Secure للمعاملات عالية القيمة.

16. طبقة الامتثال: GDPR وPCI DSS 4.0 وSOC 2 وHIPAA

الأمان والامتثال بيتداخلوا بس مش نفس الشيء. ممكن تكون آمن تقنيًا وغير ممتثل (الورق ناقص)، أو ممتثل على الورق وغير آمن في الممارسة. لمعظم الشركات، الأنظمة المنطبقة هي:

GDPR (أي شركة عندها عملاء في الاتحاد الأوروبي): حق الوصول، حق الحذف، إشعار اختراق خلال 72 ساعة، أساس قانوني للمعالجة، تقييمات تأثير حماية البيانات للمعالجة عالية المخاطر. الغرامات حقيقية، تصل لـ 4% من الإيرادات العالمية.

PCI DSS 4.0 (أي حد بيلمس بيانات كروت): تحديث 2024 جاب متطلبات جديدة كبيرة، بما فيها مصادقة أكثر صرامة، تسجيل أكثر تفصيلًا، ومراقبة مستمرة. تقليل النطاق عبر حقول الدفع المستضافة هو الحركة عالية الفاعلية.

SOC 2 (B2B SaaS بتبيع للمؤسسات): تقرير SOC 2 Type II بقى تكلفة الدخول لعقود المؤسسات. Vanta وDrata وSecureframe بيؤتمتوا معظم جمع الأدلة. خصّص 6-12 شهر لأول مراجعة.

HIPAA (الرعاية الصحية الأمريكية): بيانات المرضى عندها قواعد تشفير ووصول وتسجيل وإشعار اختراق محدّدة. معظم مزوّدي السحابة بيقدّموا فئات خدمة مؤهّلة لـ HIPAA، استخدمها.

تشيك ليست أمان المواقع 2026 في المقال ده هتوصلك 80% من الطريق لأي نظام امتثال. الـ 20% المتبقية هي توثيق وتدريب وشهادة طرف ثالث.

17. تكلفة المراجعة الأمنية مقابل تكلفة الاختراق في 2026

نتكلم بالأرقام، لأن الإنفاق الأمني دايمًا بيتم وزنه ضد البدائل.

مراجعة تشيك ليست أمان موقع احترافية لـ SaaS عادي أو موقع تجارة إلكترونية بتكلف بين 1,500 و8,000 دولار حسب النطاق. اختبار اختراق (استغلال نشط، مش مجرّد مراجعة) بيكلف 5,000 لـ 25,000 دولار. مراجعة SOC 2 سنوية بتكلف 15,000 لـ 80,000 دولار شاملة.

تقرير IBM Cost of a Data Breach بيحط متوسط الاختراق في 2025 على 4.88 مليون دولار عالميًا و1.18 مليون دولار للمؤسسات تحت 500 موظف. حتى لو خصمت المتوسط ده بـ 80% للشركات الصغيرة جدًا، بتبص على تكاليف حادثة بستة أرقام لما تحط في حسبانك retainers الاستجابة للحوادث (200-500 دولار/ساعة، غالبًا بحد أدنى 50 ساعة)، استشارة قانونية، تكاليف إشعار العملاء (غالبًا 5-15 دولار لكل سجل متأثر)، عروض مراقبة الائتمان، الغرامات التنظيمية، والضرر بالعلامة التجارية الأصعب في القياس.

الحسبة مش دقيقة بشكل غامض. مراجعة بـ 5,000 دولار بتمنع حادثة بـ 200,000 دولار لها عائد على الاستثمار 4,000%. وعلى عكس معظم الإنفاق التسويقي، العائد ده بيتراكم، كل سنة تتجنب فيها حادثة هي سنة ثقة عميل متراكمة.

18. إمتى تعمل التشيك ليست بنفسك مقابل توظيف متخصص

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

اعمل التشيك ليست بنفسك لو: عندك مطوّر سينيور كفء، بياناتك غير حساسة (موقع تسويقي، مدونة، أداة داخلية)، إنت قبل الإيرادات أو تحت 100 عميل، وعندك وقت تتعلم. cheat sheets بتاعت OWASP والمقال ده وعطلة نهاية الأسبوع هيوصلوك لوضعية B+.

وظّف متخصص لو: بتتعامل مع بيانات دفع، بتتعامل مع PII صحي أو مالي، بتقفل صفقات مؤسسات بتتطلب SOC 2، عندك حادثة قبل كده (متكرّرهاش)، أو بتتحرك بسرعة والأمان بيتزحلق دايمًا. متخصص على retainer بـ 1,500-3,000 دولار في الشهر أرخص من مهندس فُل تايم تاني وبيديك ضمان مراجعة قبل النشر.

الأرضية الوسطى، واللي بعملها لمعظم العملاء، هي مراجعة ربع سنوية. ثلاث أو أربع مرات في السنة، مجموعة عيون خارجية بتمشي على تشيك ليست أمان المواقع 2026 مع فريقك، تفتح تذاكر للفجوات، وتوقّع على المعالجة. ده الإنفاق الأمني بأعلى فاعلية معظم الشركات النامية تقدر تعمله. لو بتفكر تجيب ده داخل الشركة ولا تستأجره من برّه، مقالي عن المطوّر المستقل مقابل الوكالة ينطبق على شغل الأمان كمان.

19. نظرة مستقبلية: Passkeys والهجمات المدعومة بالذكاء الاصطناعي وTLS ما بعد الكم

بصة بعد 2026، ثلاث تحولات تستحق الاستعداد ليها دلوقتي.

Passkeys بتحل محل الباسووردات. Apple وGoogle وMicrosoft كلهم بيدعموا WebAuthn passkeys محليًا. هي مقاومة للتصيد، مقاومة لاختراق السيرفر، وUX أحسن من الباسووردات. ضيف دعم passkey لمسار المصادقة بتاعك السنة دي، مستخدمينك هيتبنّوها أسرع مما تتوقع.

الهجمات المدعومة بالذكاء الاصطناعي بتتوسع. المهاجمون بيستخدموا LLMs لكتابة تصيد مقنع بأي لغة، توليد كود استغلال من أوصاف CVE في دقائق، وأتمتة الاستطلاع بمقياس ماكانش ممكن قبل كده. الدفاع كمان مدعوم بـ AI، كشف الشذوذ، البيومتركس السلوكي، الفرز الأوتوماتيكي للتنبيهات. عدم التماثل هيشتد، بس المدافعين محتاجين يستثمروا في الأدوات.

TLS ما بعد الكم قادم. NIST أنهت معايير التشفير ما بعد الكم والمتصفحات وجهات الإصدار الكبرى بتطرح تبادل مفاتيح هجين ما بعد الكم. مش محتاج تعمل حاجة خاصة لسه، TLS stack بتاعك هياخد ده عبر التحديثات، بس كن مدركًا إن تهديد harvest-now-decrypt-later حقيقي للبيانات اللي بتشفّرها النهارده ومحتاجة تفضل سرية في 10+ سنين. للاتجاهات الأوسع، شوف ملخصي عن اتجاهات تطوير الويب 2026.

20. أسئلة شائعة عن أمان المواقع

كل قد إيه أشغّل مراجعة تشيك ليست أمان موقع؟

كحد أدنى مرة في السنة، مع سكان سريع بعد أي إصدار رئيسي. للمواقع عالية المخاطر (تجارة إلكترونية، رعاية صحية، فينتك)، ربع سنوي هو الإيقاع الصح. السكانات الأوتوماتيكية لازم تشتغل على كل deploy. التشيك ليست نفسها بتاخد من مهندس سينيور حوالي 8 ساعات يمشيها من الأول للآخر لموقع عادي.

هل محتاج WAF لو اتبعت التشيك ليست دي؟

Web Application Firewall هو دفاع متعدد، مش بديل عن كود آمن، بس طبقة إضافية مفيدة بتسد أنماط الهجوم المعروفة على الحافة قبل ما توصل لتطبيقك. قواعد Cloudflare WAF المجانية بتمسك معظم الفحص الأوتوماتيكي. لأهداف عالية القيمة، WAF مُدار بقواعد مخصّصة بيستحق تكلفته. متستخدمش WAF كعذر تنزّل كود غير آمن.

إيه أعلى تغيير أمني أثرًا أقدر أعمله النهارده؟

فعّل 2FA على كل حساب أدمن وظبّط rate limiting على رابط تسجيل الدخول. التركيبة دي لوحدها بتهزم credential stuffing وbrute force، اللي مع بعض بيمثلوا أغلبية اختراقات الشركات الصغيرة. بياخد بعد الضهر ومتكلّفش حاجة.

إزاي أعرف لو موقعي اتخرق فعلاً؟

بصراحة؟ غالبًا ماتعرفش، إلا لو كنت بتشحن لوجز خارج الجهاز وبتراقبها. علامات تبص عليها: مستخدمين أدمن غير متوقّعين، ملفات اتعدّلت في تواريخ ماعملتش فيها deploy، ترافيك صادر لـ IPs غير مألوفة، نتائج محرك بحث لصفحات مشبوهة على دومينك، وشكاوى عملاء عن إيميلات غريبة. لو شاكك في اختراق، اخد النظام أوفلاين (متمسحوش، محتاج الأدلة) واتصل بمستجيب حوادث.

هل البرمجيات مفتوحة المصدر أقل أمنًا من البرمجيات التجارية؟

مش بطبيعتها. مفتوح المصدر معناه عيون أكتر تقدر تلاقي bugs، بس كمان معناه المهاجمين يقدروا يقرأوا الكود. العامل الأكبر هو الصيانة: مشروع مفتوح المصدر متصان كويس (Laravel وDjango وNext.js وReact) من بين أكتر البرمجيات أمانًا اللي تقدر تشغّلها. مشروع مفتوح المصدر مهجور، أو منتج مغلق المصدر من مزوّد بطّل ترقيع، خطر بصرف النظر عن الترخيص.

إزاي بيأثّر التصميم mobile-first على أمان الموقع؟

Mobile-first معناه API endpoints أكتر، مسارات OAuth أكتر، وحالات حدّية أكتر لإدارة الجلسات، كل واحدة منهم سطح هجوم لازم يتأمن. متصفحات الموبايل عندها سلوك كوكي مختلف، خصوصًا في سياقات الطرف الثالث. دليلي لتصميم الويب mobile-first بيغطي جانب UX، من زاوية الأمان، تعامل مع views الموبايل وAPIs بنفس الصرامة زي الديسكتوب. نفس الكلام ينطبق على progressive web apps، فين service workers بتضيف طبقة كاش جديدة لازم تتلغى صحيح عند تسجيل الخروج.

هل ألاقي قلق من تحميل موقعي ببطء بسبب security headers؟

لأ. HTTP security headers بتضيف كام مئة بايت لكل استجابة، مش محسوس. TLS 1.3 فعلاً أسرع من TLS 1.2. Rate limiting بيضيف ميكروثواني. لو موقعك بطيء، السبب غالبًا في حتة تانية، استعلامات قاعدة بيانات غير مخزّنة، صور كبيرة، أو جافاسكريبت بيحجب الـ render. شوف ليه موقعك بيحمل ببطء للأسباب الحقيقية.

إيه عن أمان الـ API بالتحديد؟

الـ APIs بتتبع نفس التشيك ليست مع كام إضافة: المصادقة عبر توكنات قصيرة العمر (JWT أو OAuth) بدل الجلسات، rate limiting إلزامي لكل مفتاح API، توقيع طلبات للعمليات الحساسة، وإصدارات صريحة عشان تقدر تهجر endpoints غير آمنة. أفضل ممارسات تصميم API لسنة 2026 بتغطي جانب التصميم، من ناحية الأمان، تعامل مع كل endpoint كأنه هيتنادى من عميل عدائي لأنه في النهاية هيتنادى.

21. الخطوات التالية: احجز مراجعة أمنية بأولوية

تشيك ليست أمان المواقع 2026 دي هي نفسها اللي بستخدمها على كل ارتباط مدفوع. اطبعها. سلّمها لمطوّرك. امشي عليها سطر سطر. لو قدرت تشيك بصدق كل الـ 23 بند، إنت فعلاً عملت لوضعيتك الأمنية أكتر من 95% من الشركات أونلاين النهارده.

لو ضربت في حيطة، لو في بنود ماتفهمهاش، أو بنود مش متأكد إزاي تنفّذها، أو بنود بتشك إن الإجابة فيها "لأ" بس مش متأكد، هنا أنا بدخل. بشغّل مراجعة أمنية مركّزة تغطي كل الثلاثة وعشرين ضابط، تتسلّم كتقرير مكتوب بنتائج مرتّبة بالأولوية وتقييمات خطورة وخطوات معالجة ملموسة. المراجعة الكاملة بتاخد أسبوع وهيبقى عندك كل اللي محتاجه عشان تصلّح الفجوات بنفسك أو تكلّف طرف ثالث. سواء بتطلق SaaS جديد (شوف دليلي لـ SaaS MVP)، أو بتختار stack frontend (دي مقارنتي React مقابل Vue)، أو بتثبّت موقع في الإنتاج، الأمان لازم يكون في النطاق.

لتفاصيل نموذج ارتباطي ورسومي وتوافري الحالي، شوف صفحة الخدمات. أو تخطّى لقدّام واحجز استشارة مجانية 30 دقيقة، هنمشي على أعلى خمس بنود في التشيك ليست دي مع بعض، وهتسيب المكالمة بإحساس واضح عن مكانك وإيه اللي تعمله بعد كده. مفيش ضغط بيع، مفيش upsell. يا إحنا نتناسب ونشتغل مع بعض، يا إنت تمشي بصورة أوضح لوضعيتك الأمنية مما كان عندك قبل كده. في الحالتين، إنت تكسب. وعملاؤك يكسبوا، لأن المهاجم الجاي اللي هيسكان موقعك هيلاقي الباب اتقفل أخيرًا.