هدرهای امنیتی که هر سایت کسب‌وکاری باید داشته باشد

خیلی از سایت‌ها فرض می‌کنند فعال کردن HTTPS برای امن بودن اتصال کافی است. شروع بسیار خوبی است، ولی همه‌ی ماجرا نیست. قفل کنار نوار آدرس فقط به بازدیدکننده می‌گوید ارتباط بین مرورگر و سرور شما رمزگذاری شده است. درباره‌ی این‌که مرورگر بعد از دریافت صفحه‌ها اجازه دارد چه کارهایی با آن‌ها بکند چیزی نمی‌گوید. پاسخ آن سؤال دوم را مجموعه‌ی کوچکی از هدرهای پاسخ HTTP می‌دهد و نادیده گرفتن‌شان حتی وقتی قفل کاملاً سالم به نظر می‌رسد، چند حمله‌ی رایج را ممکن می‌گذارد.

خبر خوب این است که این هدرها ارزان هستند. اضافه کردن‌شان معمولاً یک بعدازظهر کار می‌برد، نرم‌افزار جدیدی نمی‌خواهد و سطح حمله به سایت را برای همیشه کم می‌کند. این راهنما توضیح می‌دهد هر هدر چه کاری می‌کند، چطور تنظیم می‌شود و از چه اشتباه‌هایی باید پرهیز کرد، تا بتوانید با اطمینان فعالشان کنید و یک تکه کد را که نمی‌فهمید کپی نکنید.

هدرهای امنیتی چطور کار می‌کنند

هر بار که سرور شما صفحه‌ای می‌فرستد، همراهش هدرهایی هم می‌فرستد: دستورهای کوچکی در پاسخ که مرورگر قبل از نمایش هر چیزی می‌خواند. هدرهای امنیتی دستورهایی مثل «برای این دامنه فقط از HTTPS استفاده کن»، «اجازه نده سایت‌های دیگر این صفحه را در قاب خودشان بگذارند» یا «فقط اسکریپت‌هایی را اجرا کن که از این منبع‌ها آمده‌اند» هستند. مرورگر این دستورها را روی دستگاه بازدیدکننده اجرا می‌کند، پس حتی وقتی یک باگ در کد شما یا یک اسکریپت آلوده‌ی شخص ثالث می‌توانست آسیب بزند، از آدم‌های واقعی محافظت می‌کنند.

چون مرورگر آن‌ها را اعمال می‌کند، این هدرها یک لایه‌ی دفاعی اضافی هستند. جای کد امن، نرم‌افزار به‌روز و رمزهای قوی را نمی‌گیرند، که در چک‌لیست عملی امنیت سایت درباره‌شان نوشته‌ایم، ولی وقتی چیز دیگری خراب شود، آسیب را محدود می‌کنند.

Strict-Transport-Security (HSTS)

هدر HSTS به مرورگر می‌گوید فقط از طریق HTTPS به سایت شما وصل شود، حتی اگر بازدیدکننده http:// تایپ کند یا روی یک لینک قدیمی بزند. بدون آن، اولین درخواست هنوز می‌تواند قبل از هدایت سرور روی HTTP ساده برود و همین فاصله‌ی کوتاه دقیقاً همان چیزی است که مهاجم روی شبکه‌ی عمومی دنبالش است.

این هدر یک max-age بر حسب ثانیه دارد. مقدار رایج در محیط اصلی دو سال است (۶۳۰۷۲۰۰۰ ثانیه). گزینه‌ی includeSubDomains قاعده را به همه‌ی زیردامنه‌ها گسترش می‌دهد و preload اجازه می‌دهد درخواست ورود به فهرست‌هایی را بدهید که مرورگرها همراه خودشان دارند. درباره‌ی دو مورد آخر احتیاط کنید: includeSubDomains هر زیردامنه‌ای را که گواهی HTTPS معتبر ندارد از کار می‌اندازد و برگرداندن preload کار سختی است. با یک max-age کوتاه، مثلاً چند روز، شروع کنید، مطمئن شوید چیزی خراب نشده و بعد آن را افزایش دهید.

Content-Security-Policy (CSP)

CSP قدرتمندترین و سخت‌گیرترین هدر است. به شما اجازه می‌دهد دقیقاً فهرست کنید کدام منبع‌ها می‌توانند برای صفحه‌های شما اسکریپت، استایل، تصویر، فونت و اتصال تأمین کنند. اگر مهاجمی بتواند یک تگ اسکریپت تزریق کند، یا یکی از اسکریپت‌های شخص ثالثی که استفاده می‌کنید آلوده شود، یک سیاست خوب جلوی بارگذاری یا اجرای آن را می‌گیرد.

یک سیاست شروع ساده همه‌چیز را به دامنه‌ی خودتان محدود می‌کند و فقط چیزهایی را که لازم دارید باز می‌کند. فریم‌ورک‌های مدرن اغلب برای راه‌اندازی خودشان به اسکریپت درون‌خطی نیاز دارند و به همین دلیل بسیاری از سیاست‌های واقعی با script-src آزادتر شروع می‌شوند و بعداً با nonce، یعنی مقدارهای یکتا که برای هر درخواست تولید می‌شوند، سخت‌تر می‌شوند. امن‌ترین روش اجرای CSP این است که اول در حالت گزارش‌دهی (report-only) فعالش کنید. در این حالت مرورگر تخلف‌ها را گزارش می‌کند بدون این‌که چیزی را مسدود کند، پس می‌توانید ببینید سایتتان واقعاً چه چیزهایی را بارگذاری می‌کند و قبل از اعمال، سیاست را اصلاح کنید. اعمال کورکورانه‌ی یک سیاست سخت‌گیرانه راه مطمئنی است برای این‌که فرم تماس یا ابزار آمارتان را در روز انتشار خراب کنید.

X-Content-Type-Options

مقدار nosniff به مرورگر می‌گوید به نوع محتوایی که سرور اعلام کرده اعتماد کند و حدس نزند. بدون آن، ممکن است مرورگر تصمیم بگیرد یک فایل متنی بارگذاری‌شده در واقع اسکریپت است و آن را اجرا کند. این هدر هیچ عیبی ندارد و اضافه کردنش یک خط است.

Referrer-Policy

وقتی بازدیدکننده روی لینکی در سایت شما می‌زند، مرورگر ممکن است آدرس صفحه‌ای را که از آن آمده به مقصد بفرستد. این آدرس می‌تواند اطلاعاتی داشته باشد که نمی‌خواهید به اشتراک گذاشته شود، مثل مسیرهای داخلی یا پارامترها. مقدار پیش‌فرض معقول strict-origin-when-cross-origin است که برای درخواست‌های داخل سایت خودتان آدرس کامل را می‌فرستد، هنگام خروج از سایت فقط نام دامنه را و اگر مقصد امن‌تر نباشد هیچ چیز نمی‌فرستد.

Permissions-Policy

این هدر دسترسی به قابلیت‌های قدرتمند مرورگر مثل دوربین، میکروفون و موقعیت مکانی را کنترل می‌کند. حتی اگر سایت شما هرگز از آن‌ها استفاده نمی‌کند، محدود کردنشان یعنی یک اسکریپت آلوده هم نمی‌تواند بی‌سروصدا آن‌ها را درخواست کند. برای بیشتر سایت‌های کسب‌وکاری، تنظیم درست غیرفعال کردن هر چیزی است که استفاده نمی‌کنید.

جلوگیری از clickjacking: هدر X-Frame-Options و frame-ancestors

در حمله‌ی clickjacking، سایت شما نامرئی داخل صفحه‌ی دیگری بارگذاری می‌شود و بازدیدکننده فریب می‌خورد که روی دکمه‌های شما کلیک کند. جلوگیری از آن با کنترل این است که چه کسانی می‌توانند صفحه‌های شما را داخل یک قاب بگذارند. هدر قدیمی‌تر X-Frame-Options با مقدارهایی مثل SAMEORIGIN است و معادل مدرن آن دستور frame-ancestors در CSP است. تنظیم هر دو بی‌ضرر است و مرورگرهای قدیمی‌تر را هم پوشش می‌دهد.

تنظیم هدرها در Next.js

در پروژه‌ی Next.js می‌توانید هدرها را برای همه‌ی مسیرها در next.config.ts تعریف کنید:

async headers() {
  return [
    {
      source: "/(.*)",
      headers: [
        { key: "Strict-Transport-Security", value: "max-age=63072000; includeSubDomains" },
        { key: "X-Content-Type-Options", value: "nosniff" },
        { key: "Referrer-Policy", value: "strict-origin-when-cross-origin" },
        { key: "X-Frame-Options", value: "SAMEORIGIN" },
        { key: "Permissions-Policy", value: "camera=(), microphone=(), geolocation=()" },
      ],
    },
  ];
}

تنظیم هدرها روی هاست Apache یا cPanel

اگر سایت شما روی هاست اشتراکی با Apache اجرا می‌شود، معمولاً می‌توانید همین هدرها را با دستور Header در فایل .htaccess اضافه کنید، به شرطی که ماژول mod_headers فعال باشد:

<IfModule mod_headers.c>
  Header always set X-Content-Type-Options "nosniff"
  Header always set Referrer-Policy "strict-origin-when-cross-origin"
  Header always set X-Frame-Options "SAMEORIGIN"
</IfModule>

کوکی‌ها هم همین دقت را می‌خواهند

هدرها کوکی‌ها را هم کنترل می‌کنند. هر کوکی‌ای که نشست یا هویت کاربر را حمل می‌کند باید با Secure علامت‌گذاری شود تا فقط روی HTTPS ارسال شود، با HttpOnly تا اسکریپت‌ها نتوانند آن را بخوانند و با SameSite تا به‌صورت پیش‌فرض به درخواست‌های بین‌سایتی ضمیمه نشود. این ویژگی‌ها فقط چند کلمه‌ی اضافه در تعریف کوکی‌اند و دسته‌های کاملی از سرقت نشست را مسدود می‌کنند.

چیزی را که منتشر می‌کنید آزمایش کنید

بعد از فعال کردن هدرها، به‌جای فرض کردن، آن‌ها را بررسی کنید. اسکنرهای رایگانی مثل securityheaders.com و Mozilla Observatory هدرهای پاسخ شما را نمره می‌دهند و هر یافته را توضیح می‌دهند. بعد مسیرهای مهم سایت را در یک مرورگر واقعی بگردید: فرم‌ها، پرداخت، ویدیوهای جاسازی‌شده، ابزارک چت. هدری که بیش از حد سخت‌گیر باشد به‌صورت خطا در کنسول مرورگر دیده می‌شود و خیلی بهتر است خودتان آن را پیدا کنید تا این‌که از یک مشتری بشنوید.

آیا فایده‌ی سئویی هم دارد؟

هدرهای امنیتی عامل مستقیم رتبه نیستند و ادعای خلاف آن درست نیست. فایده‌ی آن‌ها غیرمستقیم است. ابزارهای ارزیابی مثل Lighthouse نبودن این محافظت‌ها را در بخش بهترین روش‌ها گزارش می‌کنند، سایتی که هک شود خیلی سریع رتبه و اعتبارش را از دست می‌دهد و مرورگرها هم روزبه‌روز بیشتر درباره‌ی صفحه‌های ناامن به کاربر هشدار می‌دهند. محافظت از سایت یعنی محافظت از ترافیکی که با زحمت به دست آورده‌اید. اگر می‌خواهید این تنظیمات را برایتان انجام دهیم و پایش کنیم، خدمات پشتیبانی و نگهداری سایت ما بررسی هدرها را هم شامل می‌شود و در خدمات طراحی سایت و توسعه وب آن‌ها را از همان ابتدا در پروژه پیاده می‌کنیم.