Code Sphere by Mahmoud Ali

Code Sphere by Mahmoud Ali 🚀 Hi, I’m Mahmoud Ali, the mind behind Code Sphere. I create modern full-stack web projects using React, Next.js, Node.js, and more.

🌐 بنساعد المطورين وعشاق التكنولوجيا بمحتوى بسيط عن البرمجة، الأدوات الحديثة، والفرص الجديدة.
👨‍💻 أنا محمود علي، مطور ويب وشغوف بنشر كل جديد.
🚀 انضم لينا وخليك جزء من رحلة التطوير والإبداع! Follow for tips, projects, and dev content that makes coding easier and smarter.

20/03/2026

بوست خفيف في العيد
يعني إيه Compiled و Interpreted بلسان مبرمج MERN؟ 💻🔥

لو فاكر إن الفرق بس في "السرعة"، يبقى محتاج تعمل Update للمعلومات دي:

🧱 الـ Compiled (زي C++, Rust, Go):

الـ Logic: الكود بيتحول لـ Machine Code "كتلة واحدة" قبل ما يشتغل.

الميزة: طلقة في التنفيذ (Performance)، والأخطاء بتبان وأنت بتكتب (Compile-time).

العيب: أي تعديل بسيط بيخليك تعيد الـ Process من الأول.

🗣️ الـ Interpreted (زي Python, JS, PHP):

الـ Logic: الكود بيترجم "سطر بسطر" وقت ما البرنامج شغال (Runtime).

الميزة: مرونة مرعبة وسرعة في التطوير (Fast Development).

العيب: أبطأ شوية لأن فيه "مترجم" شغال في النص لحظة بلحظة.

⚠️ طب والـ TypeScript والـ JavaScript؟

هنا بقى الـ Tricky Part:

الـ JS هي لغة Interpreted بامتياز، البراوزر بيقرأها وينفذ سطر سطر.

الـ TS هي لغة Compiled (تقنياً Transpiled). البراوزر مبيفهمش TS، عشان كدة فيه Compiler بياخد كودك يفتشه، يتأكد إن الـ Types صح، وبعدين "يحوله" لـ JS.

الخلاصة: الـ TS بتديك أمان الـ Compiled مع مرونة الـ JS.

متنساش تتابع Code Sphere و تشارك مشاريعك و أفكارك
و دي قناة اليوتيوب بتاعتنا https://www.youtube.com/

20/03/2026

✨ Code Sphere بتقولكم كل سنة وأنتم طيبين ❤️

بمناسبة العيد، حابين نبعتلكم شوية positive vibes كده في الtimeline 🎉
يا رب حياتكم تبقى smooth زي clean code 💻
والأيام الجاية تبقى مليانة success زي deploy من غير errors 🚀

عيد سعيد عليكم وعلى كل اللي بتحبوهم 🤍
ومتنسوش تاخدوا break شوية من الdebugging وتستمتعوا بالعيد 😄

ده آخر بوست ليا قبل ما أدخل الجيش، وحبيت يكون عن حاجة فعلًا بتفرق في شغل الباك إند، مش Framework جديد ولا شوية Syntax.أغ...
07/01/2026

ده آخر بوست ليا قبل ما أدخل الجيش، وحبيت يكون عن حاجة فعلًا بتفرق في شغل الباك إند، مش Framework جديد ولا شوية Syntax.

أغلبنا بيكتب Backend إزاي؟ 🤔 غالباً بالشكل ده: route ← controller ← mongoose model

والـ controller بيعمل كل حاجة: ✅ يستقبل request ✅ يعمل validation ✅ يحسب logic ✅ يكلم الداتابيز ✅ ويرجع response وبيشتغل.. لكن المشكلة مش هنا!

المشكلة الحقيقية: إن كل المسؤوليات متلخبطة في مكان واحد. وده بيخلّي: ❌ الكود صعب الفهم. ❌ صعب الاختبار (Testing). ❌ صعب التعديل. ❌ وأصعب لما المشروع يكبر (Scaling).

Clean Architecture = تنظيم المسؤوليات 🎯 معناها إن كل جزء يعمل حاجة واحدة بس مش أكتر.

أهم نقطة: الـ Business Logic vs Data Access

🔹 Business Logic (Service Layer): ده "عقل" السيستم، مسؤول عن القوانين، القرارات، الشروط، ومين مسموحله يعمل إيه. ❗ مهم جداً: الـ Business Logic عمره ما يكلم الداتابيز مباشرة.

🔹 Data Access (Repository Layer): ده الجزء الوحيد اللي بيكلم MongoDB أو يستخدم Mongoose. مسؤول عن الـ Queries فقط (find, create, update, delete).
❗ مهم: الـ Repository ميعرفش حاجة عن الـ Business rules.

الطبقات كلها بتشتغل إزاي؟ 🔁

1️⃣ Routes: بتوصل الـ URL بالـ controller بس.

2️⃣ Controller (HTTP Layer): مسؤول عن الـ req والـ res بس.

3️⃣ Service (Business Logic): هنا التفكير، الـ rules، والقرارات.

4️⃣ Repository (Data Access): هنا الداتابيز فقط.

5️⃣ Model: ده شكل الداتا وخلاص.

ليه الـ Separation of Concerns مهم؟

كل ملف يبقى سهل يتقري.

أي تعديل يبقى واضح مكانه.

أي حد يدخل المشروع بعدك يفهمه بسهولة.

Dependency Injection (DI) 💉 بدل ما كل ملف يعمل require لكل حاجة، بنستخدم Container واحد يبني السيستم:

Model ← Repository ← Service ← Controller
ده بيقلل الترابط، بيسهل الـ Testing، وبيخلي المشروع Scalable بجد.

ليه الطريقة التقليدية مش كفاية؟ الطريقة السريعة تنفع لـ Demo أو Task صغير، لكنها متستحملش مشروع كبير، ولا Features كتير، ولا Team كامل شغال مع بعض.

👨‍💻 ملحوظة مهمة: لو حسّيت إن استخدام الـ class أو الـ constructor تقال شوية، أنا شارح الـ OOP في JavaScript ببساطة جداً في البلاي ليست دي: 🎥 https://www.youtube.com/watch?v=N1Z3AaynzH8&list=PLWbbqelFsLWngJfy5phSV69K2vBEJklJR

🪖 كلمة أخيرة: ده آخر بوست ليا قبل الجيش. الكود هيستنى، لكن التفكير الصح في البرمجة هو اللي بيفضل.

لو مهتم بالـ Backend والـ Best Practices، تابع وشارك معانا في Code Sphere عشان نتعلم ونكبر سوا ❤️

27/12/2025

Shout out to my newest followers! Excited to have you onboard! Ahmed Mohamed-Fouad, Ili NA, Agib Saad

ليه تستخدم Lenis Library في موقعك؟وأنت بتتصفح أي موقع، أول حاجة بتحسّها من غير ما تاخد بالك هي الـ Scroll.لو الحركة تقيل...
19/12/2025

ليه تستخدم Lenis Library في موقعك؟

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

هنا بقى ييجي دور Lenis Library.

Lenis هي مكتبة JavaScript بتخلّي حركة التصفح ناعمة وسلسة، وتدي إحساس إن الموقع متظبط واحترافي. عشان كده بتتستخدم كتير في مواقع الشركات، الـ landing pages، والـ portfolios اللي مهتمة بتجربة المستخدم.

بتستخدم Lenis في إيه؟

Lenis مناسبة جدًا لو عايز:

تحسين تجربة المستخدم (UX)

Smooth Scroll مريح للعين

تحكم كامل في حركة الصفحة

موقع يسيب انطباع قوي من أول زيارة

الـ Scroll مش تفصيلة صغيرة… ده جزء أساسي من إحساس المستخدم بالموقع.

فكرة الكود باختصار

الفكرة كلها إننا:
نشغّل Lenis مرة واحدة، ونستخدمها في الموقع كله.

علشان كده اتحطّت في ملف utils:

عشان تبقى reusable

وسهل التحكم فيها

ومن غير تكرار أو مشاكل أداء

فيه instance واحدة بس من Lenis، لو موجودة بنستخدمها، ولو مش موجودة بننشئها. الأسلوب ده بيخلّي الكود أنضف وأثبت.

ليه الإعدادات دي مهمة؟

الإعدادات بتحدد إحساس الحركة نفسها:

سرعة الانتقال

نعومة الـ easing

التفاعل مع الماوس والموبايل

النتيجة Scroll طبيعي ومريح، لا بطيء ولا مزعج.

ليه بنستخدم Animation Loop؟

Lenis بتشتغل مع requestAnimationFrame
وده بيخليها متزامنة مع أي animation في الصفحة.

وده معناه:

حركة أنعم

أداء أفضل

تجربة مستخدم ثابتة

تشغيل Lenis على مستوى الموقع

في ملف الـ root:

Lenis بتشتغل أول ما الصفحة تفتح

وبتبقى متاحة على window

كده تقدر تتحكم في الـ scroll من أي مكان في المشروع، سواء بزرار، event، أو interaction معين.
👉 دلوقتي Lenis شغالة فعليًا في الموقع كله

التحكم في Scroll بعنصر مخصص

مثال بسيط: زرار “Scroll To Top”

لو Lenis موجودة → نستخدمها

لو مش موجودة → نرجع للـ scroll العادي

الأسلوب ده بيخلّي الكود مرن، وآمن، واحترافي.

الخلاصة

Lenis مش مجرد مكتبة Scroll،
دي أداة بتحسّن تجربة المستخدم وبتدي للموقع إحساس هادي وpremium.

لو بتشتغل Frontend وعايز مستوى شغلك يعلى خطوة:
👉 Lenis Library اختيار ذكي

لو حابب:
تشارك مشاريعك
تتعلّم best practices
تشوف تطبيقات حقيقية
تناقش أفكار Frontend بشكل عملي

📌 تابع Code Sphere وشاركنا شغلك
الهدف إننا نتعلّم من بعض ونطوّر نفسنا سوا 💪

#برمجة

🚀 وقت الأنيميشن… دلوقتي!مكتبة AOS (Animate On Scroll) هي مكتبة خفيفة متخصصة في تشغيل أنيميشن عند التمرير (scroll)، وبتوف...
20/11/2025

🚀 وقت الأنيميشن… دلوقتي!

مكتبة AOS (Animate On Scroll) هي مكتبة خفيفة متخصصة في تشغيل أنيميشن عند التمرير (scroll)، وبتوفر طريقة سريعة وسهلة تضيف حركات للـ DOM فقط باستخدام attributes HTML (مثل data-aos="fade-up"). ميزتها الأساسية إنك مش محتاج تكتب كود أنيميشن معقد — بتحط صفة على العنصر وتسيب الباقي للمكتبة.

مزايا AOS كـمكتبة:
سهل الدمج: تقدر تضيفها في مشروع React أو Next.js بسرعة عبر npm/yarn أو CDN.

قائم على الـ attributes: ما فيش حاجة لكتابة keyframes أو JS معقد — توصف العنصر بالصّفة وتتحكم في الإعدادات.

لكن !!
ليست مكتبة تحكمية متقدمة للـ interactions أو physics (زي Framer Motion).

الأنيميشن محدودة بالأنماط والانتقالات المسبقة — للتفاعلات المعقدة هتحتاج حلول أقوى.

لو استخدمت بكثافة بدون تحسين، ممكن تأثر على أداء الصفحة.

استخدم once: true للأنيميشن التي لا تحتاج إعادة عند العودة للعنصر — يقلل إعادة الحسابات.

لا تضع أنيميشن على كل عنصر صغير؛ اختصرها على العناصر المهمة فقط.

لو عايز الكود: شوف الـ snippet

تابعوا Code Sphere لمشاركة مشاريعكم وافكاركم وطرق تحقيق أرباح من المحتوى البرمجي.
تابِعني على LinkedIn https://www.linkedin.com/in/mahmoudali-webdev/
وYouTube https://www.youtube.com/
وشارك البوست — كل الدعم يصنع فرق.

يا جماعة معلش على الغياب الفترة اللي فاتت 🙈كنت مشغول شوية، بس راجعلكم بحاجة بسيطة جدًا…بس والله بتفرق جامد في تنظيم الكو...
05/11/2025

يا جماعة معلش على الغياب الفترة اللي فاتت 🙈
كنت مشغول شوية، بس راجعلكم بحاجة بسيطة جدًا…
بس والله بتفرق جامد في تنظيم الكود وراحة دماغك أثناء الشغل 💪
النهارده هنتكلم عن:

إزاي تدير Modals في React

🎯 المشكلة
في أي مشروع متوسط أو كبير، دايمًا بيكون عندك كذا Modal:

واحد للإنشاء

واحد للتعديل

واحد للحذف

وممكن كمان rollback أو save...

وهنا تبدأ المعاناة 😅
تلاقي نفسك عامل state لكل مودال، والكود بيطول جدًا ومش منظم.

🧩 الطريقة الأولى — State لكل Modal
الطريقة دي هي الأبسط، وكل الناس بدأت بيها في يوم من الأيام.
الفكرة إن كل مودال له state خاص بيه:
true لو مفتوح، و false لو مقفول.

🧠 الفكرة:

كل مودال ليه state خاص (زي isCreateOpen, isEditOpen...)

المودال بيتفتح لما تضغط زرار معين

بيتقفل بـ onClose لما المستخدم يخلص

الكود بيبقى واضح جدًا، لكن لو عندك 8 أو 10 مودالات...
هتبدأ تحس إن الصفحة كبرت منك 😩

✅ المميزات:

سهل جدًا لأي مبتدئ.

الكود مباشر وواضح.

❌ العيوب:

كل مودال ليه state منفصلة → كود أطول ومكرر.

صعب التوسع مع الوقت.

⚡ الطريقة الثانية — Dynamic Modal بمتغير واحد
ودي بقى التريكة الحلوة 😎
بدل ما تعمل state لكل مودال،
بتعمل state واحدة بس اسمها currentModal،
وتخزن فيها اسم المودال المفتوح حاليًا.

🧠 الفكرة:

استخدمنا currentModal بدل 5 أو 6 states.

كل مودال ليه key جوه object اسمه modalCompMap.

لما المستخدم يضغط زرار فتح المودال، بنمرر الاسم (زي "createMachine") لـ setCurrentModal.

بناءً على القيمة، React بتعرف أي مودال تفتحه.

ولما يتقفل، بنرجع currentModal إلى null.

✅ المميزات:

كود أنضف وأقصر بكتير.

سهل جدًا تضيف مودال جديد (بس تضيفه في الماب).

قابل للتوسع بدون أي وجع دماغ.

❌ العيوب:

محتاج تبقى فاهم شوية فكرة الـ “mapping” والديناميكية في React.

💬 الخلاصة

لو مشروعك بسيط ولسه في البداية → استخدم الطريقة الأولى.
لكن لو مشروعك بدأ يكبر وفيه أكتر من 3 أو 4 مودالات → الطريقة الديناميكية هتخليك ترتاح جدًا وتكتب كود أنضف 💪

وفي الحالتين، الفكرة دي هتخليك تفهم أكتر
إزاي React بتتعامل مع الحالة والتصميم الشرطي.

👀 نصيحة:
شوف الكود بنفسك وشغّله عندك،
لما تشوف النتيجة على الشاشة،
هتحس فعلاً قد إيه التريكة دي بتخلي الكود أنضف وأسهل في الصيانة 🚀
متنساش تتابع الجروب و تشارك تريكاتك علشان الكل يستفيد Code Sphere

كما وعدتكم… النهاردة هنتكلم عن Redux Toolkit 🎯وإزاي نعمل Data Fetching بشكل منظم وسهل 🚀لما تيجي تعمل Data Fetching (زي L...
19/08/2025

كما وعدتكم… النهاردة هنتكلم عن Redux Toolkit 🎯
وإزاي نعمل Data Fetching بشكل منظم وسهل 🚀

لما تيجي تعمل Data Fetching (زي Login أو Get Todos أو أي API call) في React، دايمًا بتواجه نفس المشاكل:

إزاي أعرف إن الطلب بدأ (Loading)؟

إزاي أحفظ البيانات اللي رجعت (Data)؟

إزاي أعرض رسالة خطأ (Error) لو حصل مشكلة؟

وإزاي أخلي الحالة دي متاحة في أي مكان في التطبيق؟

Redux Toolkit بيقدملك حل منظم جدًا باستخدام createAsyncThunk + extraReducers.

🟢 createAsyncThunk

دي دالة جاهزة من RTK بتسمحلك تعرّف عملية غير متزامنة (زي الاتصال بـ API).
أنت بتديلها اسم (زي authSlice/logIn) ودالة بتحتوي منطق الطلب (بتستقبل بيانات من الفورم مثلاً وتبعتها للسيرفر).

الميزة إن createAsyncThunk أوتوماتيك بيولّدلك 3 أنواع من الأحداث (Actions):

Pending → أول ما يبدأ الطلب.

Fulfilled → لو نجح وجاب بيانات.

Rejected → لو فشل أو حصل Error.

يعني مش محتاج تكتب إيفنتات يدوياً ولا تتابعهم بنفسك.

🟡 thunkAPI

جوه createAsyncThunk بيجيلك كائن اسمه thunkAPI، وده بيديك أدوات مفيدة:

dispatch: تقدر تبعت أحداث إضافية لو عايز.

getState: تجيب حالة التطبيق الحالية.

rejectWithValue: أهم حاجة! بتسمحلك ترجع خطأ بشكل منظم بدل ما تبعت Error خام. ده يخلي Reducer يعرف يتعامل مع الرسالة أو الكود بسهولة.

🔵 extraReducers

لما تعمل Slice في Redux Toolkit، عندك مكان اسمه extraReducers.
هنا بتقول: "لو الـ async action بتاعي (مثلاً logIn) دخل في حالة pending/fulfilled/rejected، اعمل التغييرات الفلانية في الـ state".

مثال عملي:

لما الحالة pending: خلّي loading = true، وامسح أي خطأ قديم.

لما الحالة fulfilled: رجّع loading = false، وخزّن البيانات اللي رجعت (مثلاً user info أو token).

لما الحالة rejected: رجّع loading = false، وخزّن رسالة الخطأ اللي رجعت من rejectWithValue.

النتيجة: عندك state منظم يحتوي على (loading, data, error) دايمًا.

🔴 إزاي أستخدمه في الكومبوننت؟

من جوه React component:

بتستعمل useDispatch علشان تبعت (dispatch) للـ thunk اللي عرّفته. مثلاً dispatch(logIn(userData)).

بتستعمل useSelector علشان تقرا من الـ state الحالي (هل في loading؟ في error؟ في user؟).

كده الكومبوننت يقدر:

يعرض زرار "Login" ويتحول لـ "Loading..." أثناء الاتصال.

يظهر رسالة خطأ لو اليوزر دخل بيانات غلط.

يستقبل بيانات المستخدم ويعرضها لو الـ login نجح.

🟣 ليه الحالة بتفضل متاحة في كل الكومبوننتات؟

السر في حاجة اسمها Single Source of Truth:

Redux Store بيتخزن في أعلى التطبيق.

أي كومبوننت تحت الـ Provider يقدر يوصل للـ state.

يعني لو User نجح في تسجيل الدخول في شاشة الـ Login، أي شاشة تانية (Profile, Navbar, Dashboard) تقدر تقرا نفس الـ user من نفس الـ store… من غير ما تعمل Passing للبيانات عبر Props.

✨ النتيجة النهائية

createAsyncThunk بيديك طريقة جاهزة للتعامل مع الـ async.

extraReducers بتخليك تدير حالات Loading/Data/Error بشكل تلقائي.

dispatch + useSelector بتخلي الكومبوننتات تتعامل مع الـ state بسهولة.

والـ state بيبقى مركزي ومشترك في أي مكان في التطبيق.

📌 باختصار:
Redux Toolkit خلّى موضوع الـ Data Fetching اللي كان صداع في Redux العادي يبقى 3 خطوات واضحة:

عرّف thunk.

ضيف extraReducers.

استعمل dispatch + selector.

📢 استنوا البوست الجاي:
RTK Query — المستوى التاني من السهولة 👑 (Fetch + Cache + Refetch + Invalidation).

✅ ماتنساش تتابع جروب Code Sphere عشان توصلك البوستات أول بأول.
🎥 واشترك في القناة على يوتيوب:
👉 https://www.youtube.com/

مبرمج زهق من الـ props وقال: “هحط الـ state كله في localStorage وخلاص!”المتصفّح رد عليه: “جميل… لحد ما تعمّل Refresh وتك...
14/08/2025

مبرمج زهق من الـ props وقال: “هحط الـ state كله في localStorage وخلاص!”
المتصفّح رد عليه: “جميل… لحد ما تعمّل Refresh وتكتشف إنك بتبني DB في المتصفح!” 😂

ليه React-Redux؟

لما الـ app يكبر، بيحصل props drilling: تبعت بيانات من أب → ابن → حفيد… حتى لو الحفيد هو الوحيد اللي محتاجها. ده بيخلّي الكود معقّد وصعب الصيانة.

ناس كتير جرّبت حل بدائي: “حط كل حاجة في localStorage” علشان تبقى “متاحة في أي مكان”. بس ده له مشاكل:

أداء: قراءة/كتابة متزامنةBlocking وبتكبر مع حجم الداتا.

تزامن: المكوّنات مش هتعرف إن الداتا اتغيّرت تلقائيًا.

حدود حجم وأمان: مساحة محدودة ونص عادي (غير مشفّر).

Redux بيقدّم Store واحد (Single Source of Truth) + تحديثات متوقّعة (predictable).

react-redux بيربط React بالـ Store بطريقة سهلة وأداء عالي (بـ Provider, useSelector, useDispatch).

الفكرة: عندك مخزن مركزي، أي كومبوننت يقدر “يقرا” منه و“يبعت” أكشن يغيّر البيانات… من غير ما يعدّي على شجرة props كلها.

مكوّنات Redux الأساسية

Store: المخزن المركزي للـ state.

Action: كائن بسيط { type, payload } بيحكي “عايز تعمل إيه”.

Reducer: دالة نقيّة بتاخد state + action وترجع state جديد (من غير Mutation).

Provider (من react-redux): يغلّف الـ App علشان كل المكوّنات تقدر توصل للـ store.

useSelector: تقرأ جزء من الـ state.

useDispatch: تبعت Actions تغيّر الـ state.

ليه “بدون Mutation”؟ علشان سهولة التتبّع، وmemoization، وperformance أفضل.

طيب… إمتى أستخدم localStorage؟

لو عندك بيانات لازم تفضل بعد الـ refresh (زي token أو تفضيلات بسيطة).

لكن ماينفعش تعامله كبديل لـ Redux: مفيش reactivity، ومش آمن، ومساحته محدودة.

لو محتاج Persist للـ Redux state، استخدم حلول مدروسة (زي middleware مخصّص أو مكتبات persist) بدل ما “تكتب/تقرا يدويًا” في كل مكان.

وهل في بدائل لِـ Redux؟

أيوه، حسب نوع البيانات:

React Context: بديل بسيط لمشاركة state محدود (بس مش مناسب لحالات updating الثقيلة).

Zustand / Jotai / Recoil / MobX: مكتبات إدارة حالة خفيفة ومريحة.

XState: لو عندك حالات معقّدة بـ state machine.

React Query / TanStack Query: للـ server state (جلب/Cache/Sync من API) — وده مختلف عن client state (UI, flags, selections).

📌 تابع البوست الجاي

استنى الجزء التاني عن Redux Toolkit: هنعرف إزاي ندير استدعاءات الـ API جوه Redux بطريقة منظمة، ونتعامل مع حالات تحميل البيانات (Loading)، وعرض النتيجة (Data)، والتعامل مع الأخطاء (Error) من غير ما نغرق الكومبوننتات بكود زيادة، وبأقل عدد ممكن من الأسطر.

✅ تابع الجروب عشان توصلك كل البوستات Code Sphere🎥 واشترك في القناة على يوتيوب عشان تشوف الشرح العملي خطوة
بخطوة. https://www.youtube.com/

👋 يا جماعة، آسف على الغياب الفترة اللي فاتت 🙏وزي ما قلت في آخر بوست، النهاردة هنتكلم عن Helmet – المكتبة اللي هتزود أمان...
08/08/2025

👋 يا جماعة، آسف على الغياب الفترة اللي فاتت 🙏
وزي ما قلت في آخر بوست، النهاردة هنتكلم عن Helmet – المكتبة اللي هتزود أمان الباك إند بتاعك بكام سطر بس!

Helmet بيشتغل على إنه يضيف HTTP Security Headers بشكل أوتوماتيك، وده بيقلل احتمالية اختراقات كتير.
مش هيحميك من كل حاجة، لكن هيقفل فتحات كبيرة الهاكرين بيعشقوها.

1️⃣ X-DNS-Prefetch-Control
📌 يمنع المتصفح من إنه يعمل DNS Lookup لروابط قبل ما المستخدم يضغط عليها، وده بيحميك من تسريب معلومات.

لما المتصفح يشوف لينك في الصفحة، أحيانًا بيجهز نفسه من بدري ويعمل DNS lookup قبل ما المستخدم يضغط على اللينك
- ده بيسرع التصفح بس ممكن يسرب معلومات

2️⃣ X-Frame-Options (Clickjacking Protection)
📌 يمنع موقعك يتعرض جواه في iframe من موقع تاني خبيث.

**إيه هو Clickjacking؟**

- موقع خبيث يحط موقعك جوه iframe ويخليه شفاف
- المستخدم يفتكر إنه بيضغط على حاجة في الموقع الخبيث
- بس في الحقيقة هو بيضغط على زر في موقعك (زي "شراء" أو "حذف")

**مثال على الهجوم:**



Win $1000!
المستخدم يضغط على Win $1000 بس هو في الحقيقة بيضغط على زر الشراء

3️⃣ Strict-Transport-Security (HSTS)
📌 بيجبر أي متصفح يستخدم HTTPS حتى لو المستخدم كتب HTTP.

**ليه مهم؟**

- يمنع Man-in-the-Middle attacks
- يمنع Protocol downgrade attacks
- يضمن إن كل الconnections مشفرة

**إيه هو preload؟**

- قائمة جاهزة في المتصفحات فيها مواقع معروف إنها HTTPS فقط
- حتى لو المستخدم زار موقعك لأول مرة، المتصفح هيعرف إنه لازم يستخدم HTTPS

4. X-Content-Type-Options

**إيه هي مشكلة MIME Type Sniffing؟**

- المتصفح أحيانًا بيحاول "يخمن" نوع الملف لو مش واضح
- لو السيرفر بيقول الملف text/plain بس جواه HTML، المتصفح ممكن يشغله كـ HTML

**مثال على المشكلة:**

لو عندك ملف .txt فيه:

alert('XSS Attack!');

والمتصفح "خمن" إنه HTML، هيشغل الكود ده!

5️⃣ X-Permitted-Cross-Domain-Policies
📌 بيمنع Flash أو PDF clients من تحميل crossdomain.xml خطير.

**إيه هي المشكلة؟**

- Flash و PDF clients كانوا بيدوروا على ملف `crossdomain.xml` في موقعك
- لو الملف ده بيقول "اسمح للجميع"، ممكن يسرق بياناتك

Address

Assiut
Assiut
71762

Telephone

+201152821902

Website

Alerts

Be the first to know and let us send you an email when Code Sphere by Mahmoud Ali posts news and promotions. Your email address will not be used for any other purpose, and you can unsubscribe at any time.

Contact The Business

Send a message to Code Sphere by Mahmoud Ali:

Shortcuts

Share

Category