# اختبر رؤوس الأمان في HTTP وانسخ الإصلاحات

> فحص رؤوس الأمان مجانًا: قيّم HSTS وCSP وX-Frame-Options وReferrer-Policy وإعدادات الكوكيز من A+ إلى F، مع إصلاحات جاهزة لـ Apache وNginx وCloudflare.

أدخل رابطًا لتحصل على تقييم من A+ إلى F لرؤوس الأمان وإعدادات الكوكيز فيه، مع إصلاحات جاهزة للصق في خادمك.

- استخدمها مجانًا (بدون تسجيل): https://yes-seo.com/ar/security-headers-checker
- API: `GET https://yes-seo.com/api/v1/security-headers-checker?url=https://example.com`
- ما الذي تفعله: Security headers checker: grades A+ to F for Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy and cookie flags, with copy-paste fixes for Apache, Nginx and Cloudflare.

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

يطلب فاحص رؤوس الأمان هذا صفحتك ويقيّمها من A+ إلى F بحسب Strict-Transport-Security وContent-Security-Policy وX-Content-Type-Options وX-Frame-Options وReferrer-Policy وPermissions-Policy وإعدادات أي كوكيز تضبطها. ولكل رأس مفقود أو ضعيف تحصل على إصلاح جاهز للنسخ واللصق لـ Apache وNginx وCloudflare.

## كيف تفحص رؤوس الأمان

1. **أدخل رابط صفحة** — ابدأ بصفحتك الرئيسية، ثم اختبر صفحة تسجيل دخول أو دفع، حيث تهم الكوكيز والسياسات الصارمة أكثر.
2. **راجع التقييم** — اعرف الرؤوس الموجودة والمفقودة أو الضعيفة، وكيف يؤثر كل منها في التقييم الإجمالي.
3. **طبّق الإصلاحات** — انسخ المقطع المناسب لخادمك أو CDN، وانشره، وامسح الذاكرة المؤقتة، ثم أعد الفحص.

## ما الذي يفعله كل رأس أمان

| الرأس | يحمي من | قيمة بداية جيدة |
| --- | --- | --- |
| Strict-Transport-Security | الرجوع إلى HTTP، وسرقة الكوكيز على شبكات Wi-Fi المفتوحة | max-age=31536000; includeSubDomains |
| Content-Security-Policy | هجمات البرمجة عبر المواقع (XSS)، والسكربتات المحقونة | قائمة سماح مفصلة، تُختبر أولًا بوضع Report-Only |
| X-Content-Type-Options | تخمين نوع MIME | nosniff |
| X-Frame-Options | Clickjacking (الاختطاف بالنقر) | SAMEORIGIN أو DENY |
| Referrer-Policy | تسريب الروابط الكاملة إلى مواقع أخرى | strict-origin-when-cross-origin |
| Permissions-Policy | الوصول غير المرغوب إلى الكاميرا أو الميكروفون أو الموقع | camera=(), microphone=(), geolocation=() |
| علامات Set-Cookie | سرقة الجلسات، وتزوير الطلبات عبر المواقع (CSRF) | Secure; HttpOnly; SameSite=Lax |

الرأس `X-XSS-Protection` عفا عليه الزمن؛ فالمتصفحات الحديثة تتجاهله، وتوصي [MDN](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-XSS-Protection) بالاعتماد على CSP بدلًا منه. وتوجيه `frame-ancestors` في CSP هو البديل الحديث لـ X-Frame-Options، ولا بأس بإرسال الاثنين معًا. للاستزادة: [رؤوس الأمان](https://yes-seo.com/ar/glossary/security-headers) و[HSTS](https://yes-seo.com/ar/glossary/hsts).

## إعدادات جاهزة للنسخ واللصق

**Apache** (المضيف الافتراضي أو `.htaccess`، مع mod_headers):

```

  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
  Header always set X-Content-Type-Options "nosniff"
  Header always set X-Frame-Options "SAMEORIGIN"
  Header always set Referrer-Policy "strict-origin-when-cross-origin"
  Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"

```

**Nginx** (داخل كتلة `server`):

```
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
```

فخ في Nginx: كتلة `location` لها `add_header` خاص بها تُسقط كل الرؤوس الموروثة من كتلة server، فكرّرها هناك أو استخدم ملف include. والراية `always` ترسلها في صفحات الأخطاء أيضًا.

**Cloudflare:** فعّل HSTS ضمن SSL/TLS → Edge Certificates، وأضف الرؤوس الأخرى بقاعدة Transform Rule لرؤوس الاستجابة ([توثيق Cloudflare](https://developers.cloudflare.com/rules/transform/response-header-modification/)).

## طرح Content Security Policy بأمان

CSP أقوى رأس وأسهل ما يُعطّل به موقع، لأنه يحظر كل مصدر سكربت أو نمط أو خط أو إطار لم تذكره. ابدأ بوضع report-only الذي يسجل المخالفات دون حظر أي شيء:

```
Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self' https://www.googletagmanager.com; img-src 'self' data: https:; style-src 'self' 'unsafe-inline'; frame-ancestors 'self'; report-uri /csp-reports
```

راقب وحدة تحكم المتصفح ونقطة استقبال التقارير أسبوعًا أو اثنين، وأضف المصادر التي تستخدمها فعلًا، ثم غيّر اسم الرأس إلى `Content-Security-Policy`. فضّل nonces أو hashes للسكربتات المضمّنة على `'unsafe-inline'`؛ ويوثق [دليل CSP في MDN](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP) كل توجيه.

## هل تؤثر رؤوس الأمان على السيو؟

ليس مباشرة: لا تستخدم جوجل CSP أو X-Frame-Options إشارات ترتيب، وكل ما يفعله HSTS أنه يضمن وصول الزوار العائدين إلى نسخة HTTPS من موقعك. لكن المخاطر غير المباشرة حقيقية. فالموقع المخترق الذي حُقن بسبام أو برمجيات خبيثة قد يثير تحذيرات في المتصفح وعبارة «This site may be hacked» في نتائج البحث، وتنظيف ذلك يكلّف من الزيارات أكثر بكثير مما قد تكسبه الرؤوس. وافحص جانب الشهادة بـ[فحص شهادة SSL](https://yes-seo.com/ar/ssl-checker).

## نصائح لطرح رؤوس الأمان

- اضبط الرؤوس في طبقة واحدة، الخادم أو CDN، حتى لا تنتهي بقيم مكررة أو متعارضة.
- ابدأ HSTS بقيمة max-age قصيرة مثل 300 s، وتأكد أن كل نطاق فرعي يعمل عبر HTTPS، ثم ارفعها إلى سنة.
- لا تضف توجيه preload وتقدّم بطلب إلى hstspreload.org إلا بعد أن تتيقن أن كل نطاق فرعي سيبقى على HTTPS؛ فالإزالة تستغرق أشهرًا.
- اضبط Secure وHttpOnly وSameSite على كوكيز الجلسة وتسجيل الدخول في إعدادات تطبيقك أو إطار العمل.
- أعد الاختبار بعد أي تغيير في CMS أو الإضافات أو CDN، فقد تضيف الرؤوس أو تحذفها أو تستبدلها.

## حدود يجب مراعاتها

يعكس التقييم الرؤوس والكوكيز التي يعيدها الرابط الذي تختبره، دون تسجيل دخول. وقد ترسل صفحات أخرى وأنواع ملفات ومناطق مسجَّل الدخول إليها رؤوسًا مختلفة، فاختبر ما يهمك منها. والتقييم الجيد ليس تدقيقًا أمنيًا: فنحن لا نفحص الثغرات ولا البرمجيات القديمة ولا ضعف التحكم في الوصول. ولرأي ثانٍ، تُعد أداة [HTTP Observatory](https://developer.mozilla.org/en-US/observatory) من Mozilla مرجعًا جيدًا، ويعرض [فحص رؤوس HTTP](https://yes-seo.com/ar/http-header-checker) الاستجابة الخام كاملة.


## الأسئلة الشائعة

### ما هي رؤوس أمان HTTP؟

هي رؤوس استجابة تخبر المتصفحات بقواعد الأمان التي تطبقها على الصفحة، مثل فرض HTTPS، وتقييد المصادر التي تُحمَّل منها السكربتات، ومنع مواقع أخرى من تضمين الصفحة في إطار.

### أي رؤوس الأمان أهم؟

ابدأ بـ Strict-Transport-Security وX-Content-Type-Options وX-Frame-Options أو frame-ancestors في CSP وReferrer-Policy، فهي سريعة وقليلة المخاطر. أما Content-Security-Policy فيوفر أكبر حماية لكنه يحتاج إلى اختبار قبل فرضه.

### هل تحسّن رؤوس الأمان ترتيب جوجل؟

ليس مباشرة؛ فبخلاف HTTPS نفسه ليست إشارات ترتيب. هي تحمي زوارك وموقعك، والموقع المخترق يخسر من زيارات البحث أكثر بكثير مما قد يكسبه أي رأس.

### هل يمكن أن تعطّل رؤوس الأمان موقعي؟

قد يحظر Content-Security-Policy الصارم سكربتات أو خطوطًا أو محتوى مضمّنًا نسيت السماح به، وقد يحجب HSTS مع includeSubDomains النطاقات الفرعية التي لا تدعم HTTPS. اطرح CSP بوضع Report-Only وابدأ HSTS بقيمة max-age قصيرة.

### هل ما زال X-Frame-Options مطلوبًا؟

يحل توجيه frame-ancestors في CSP محله في المتصفحات الحديثة، لكن X-Frame-Options ما زال يُرسل على نطاق واسع للعملاء الأقدم. وإرسال الاثنين معًا بقواعد متطابقة آمن.

### لماذا تظهر رؤوسي في الصفحة الرئيسية ولا تظهر في الصفحات الأخرى؟

قد تنطبق قواعد مختلفة بحسب المسار أو نوع الملف. في Nginx تُسقط كتلة location لها add_header خاص بها الرؤوس الموروثة؛ وفي CMS قد تضيف إضافة رؤوسًا إلى بعض الاستجابات فقط.