---
title: "كيف تفحص كوكي الجلسة بموقعك: HttpOnly وSecure وSameSite"
description: "كوكي الجلسة هو بطاقة دخول المستخدم. تلات خصائص بسطر Set-Cookie بتقرر إذا سكربت غريب أو اتصال مكشوف أو موقع تاني بيقدر يستعملها، وبتفحصهن بخمس دقايق."
url: https://ihsanalapsi.dev/articles/session-cookie-flags-check
lang: ar
date: 2026-10-31
updated: 2026-10-31
tags: ["أمن التطبيقات", "تطوير الويب"]
author: Ihsan Alapsi (إحسان العبسي)
---
# كيف تفحص كوكي الجلسة بموقعك: HttpOnly وSecure وSameSite

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

## شو هو كوكي الجلسة، وليش بيستاهل تفحصه؟

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

السيرفر بيحط الكوكي بسطر Set-Cookie بالرد، وعلى نفس السطر بيكتب خصائصها. تلات منهن بيقرروا مين غير المستخدم بيقدر يوصل للبطاقة: HttpOnly وSecure وSameSite.

كل خاصية بتسكّر باب واحد. وإذا وحدة ناقصة، الباب يلي بتسكّره بيضل مفتوح حتى لو التانيين موجودين.

## شو بيعمل HttpOnly؟

الـ HttpOnly بيمنع الجافاسكربت يقرا الكوكي من الصفحة. هاد الباب يلي بيفوت منه أشهر هجوم على الجلسات: ثغرة XSS بتخلّي سكربت غريب يشتغل بصفحتك، والسكربت بيقرا الكوكي وبيبعتها لبرّا.

حسب [توثيق Set-Cookie على MDN](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Set-Cookie)، الكوكي يلي عليها HttpOnly ما بتطلع بـ document.cookie، بس المتصفح بيضل يبعتها مع الطلبات يلي بيعملها الجافاسكربت متل fetch(). يعني السكربت الغريب ما بيقدر يسرق البطاقة، بس بيقدر يستعملها وهو جوّا صفحتك. لهيك HttpOnly بيخفف ضرر الـ XSS وما بيلغيه، والإصلاح الحقيقي إنك تسكّر الثغرة نفسها، متل [ثغرة XSS بـ Vue I18n](/articles/vue-i18n-translation-xss) يلي كتبنا عنها.

## شو بيعمل Secure؟

الـ Secure بيخلّي المتصفح يبعت الكوكي على اتصال HTTPS بس. بلاه، أي طلب على HTTP عادي بيحمل البطاقة مكشوفة لأي حدا قاعد على نفس الشبكة.

كتير ناس بيفكروا إنو تحويل كل الموقع لـ HTTPS بيغني عنه. [ورقة إدارة الجلسات من OWASP](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html) بتقول العكس: إجبار HTTPS لحاله ما بيكفي، لأنو المتصفح ممكن ينخدع ويبعت الكوكي على HTTP إذا ما عليها Secure.

## شو بيعمل SameSite، وأي قيمة تختار؟

الـ SameSite بيحدد إذا المتصفح بيبعت الكوكي مع طلب جاي من موقع تاني. هاد الباب يلي بيفوت منه الـ CSRF: موقع غريب بيخلّي متصفح المستخدم يبعت طلب لموقعك، والمتصفح بيلزق البطاقة معه.


| القيمة | إمتى بتنبعت الكوكي                                                                    |
| ------ | ------------------------------------------------------------------------------------- |
| Strict | بس مع الطلبات الجاية من نفس الموقع                                                    |
| Lax    | من نفس الموقع، ومن موقع تاني بس لما المستخدم بينتقل لصفحتك بطلب آمن متل GET (مش POST) |
| None   | مع كل الطلبات، ولازم معها Secure                                                      |


OWASP بتفضّل Strict لكوكي الجلسة، وLax هي البديل. وبتحذّر من None بلا Secure، ومن إنك تترك القيمة للمتصفح يقررها. وحتى مع SameSite، توكن الـ CSRF بيضل لازم: هي طبقة زيادة فوقه.

## كيف بتقفل الكوكي على دومينك بالزبط؟

بتقفلها لما ما تكتب Domain أبداً، وبتسمّيها ببادئة `__Host-`. بلا Domain، الكوكي بترجع للدومين يلي عملها بس، مش للدومينات الفرعية تبعه. وإذا كتبت Domain، كل دومين فرعي بيوصلها، فصفحة منسية على دومين فرعي بتصير باب على جلسات موقعك الأساسي.

البادئة `__Host-` بتخلّي المتصفح نفسه يفرض هالقفل: الكوكي يلي اسمها بيبلّش فيها لازم يكون عليها Secure، وتنحط من صفحة HTTPS، وبلا Domain، وPath تبعها `/`. OWASP بتنصح فيها لكوكي الجلسة، وبتنصح كمان باسم عام متل `id` بدل الاسم الافتراضي تبع إطار العمل (`PHPSESSID` مثلاً)، لأنو الاسم الافتراضي بيكشف شو مشغّل.

هيك بيطلع السطر لما كل شي بمحله:

```
Set-Cookie: __Host-id=a3f9c2; Path=/; Secure; HttpOnly; SameSite=Lax
```

## كيف تفحص كوكي موقعك بخمس دقايق؟

بتفحصها من أدوات المطوّر بالمتصفح، أو بأمر curl واحد. الطريقتين بيورجوك نفس الشي، فاختار الأسهل إلك.

1. سجّل دخول على موقعك بـ Chrome، وافتح أدوات المطوّر.
2. روح لـ Application، بعدين Storage، بعدين Cookies، واختار دومين موقعك. هيك بتشرحها [صفحة الكوكيز بتوثيق Chrome DevTools](https://developer.chrome.com/docs/devtools/application/cookies).
3. لاقي كوكي الجلسة، وشوف أعمدة HttpOnly وSecure وSameSite وDomain تبعها. لازم تشوف علامة بأول عمودين، وStrict أو Lax بعمود SameSite.
4. إذا بدك تشوف السطر متل ما بيبعته السيرفر، بعت طلب تسجيل الدخول بـ curl وشوف سطور Set-Cookie:

```bash
curl -s -o /dev/null -D - https://example.com/login | grep -i set-cookie
```

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

## من وين تبلّش هلق؟

بلّش بكوكي الجلسة وحدها، مش بكل كوكيز الموقع. افتحها بأدوات المطوّر، وإذا ناقصها HttpOnly أو Secure أو SameSite، زيدهن من إعدادات الجلسة بإطار العمل تبعك، وبعدين فكّر بالبادئة `__Host-`.

وإذا بدك حدا يجرّب جلسات منصتك متل ما بيجرّبها مهاجم، من الكوكي لتسجيل الخروج، هاد شغل [مُحَصَّن](/muhassan). وكل مقالات الأمن بمكان واحد: [أمن التطبيقات](/articles?tag=app-security).

## FAQ

**إذا موقعي كله HTTPS، لسا بحتاج Secure؟**

إي. حسب OWASP، إجبار HTTPS لحاله ما بيكفي، لأنو المتصفح ممكن ينخدع ويبعت الكوكي على اتصال HTTP عادي إذا ما عليه Secure.

**هل HttpOnly بيحميني من CSRF؟**

لأ. HttpOnly بيمنع السكربت يقرا الكوكي، بس المتصفح بيضل يبعتها مع الطلبات. لـ CSRF بتحتاج SameSite وتوكن CSRF، وOWASP بتعتبر SameSite طبقة زيادة مش بديل عن التوكن.

**إذا ما كتبت SameSite، شو بيصير؟**

بيتعلّق بالمتصفح. حسب MDN بعض المتصفحات بتعتبرها Lax إذا ما انكتبت، وOWASP بتقول لا تعتمد على هالافتراضي واكتبها بنفسك على كوكي الجلسة.

**حذف الكوكي عند تسجيل الخروج بيكفي؟**

لأ. OWASP بتقول إنو حذف الكوكي ما بيبطّل نسخة مسروقة منها. الجلسة لازم تنتهي على السيرفر كمان.