افزودن یک هدر Content Security Policy می‌تواند رفتار دریافت و اجرای منابع صفحه را محدود کند، اما کپی کردن یک سیاست عمومی ممکن است فرم، تصویر یا اسکریپت ضروری سایت را از کار بیندازد. سیاستی که برای یک صفحهٔ ساده مناسب است، الزاماً با پنل مدیریت یا خدمت پرداخت سازگار نیست. این مقاله یک مسیر پیشنهادی برای طراحی و انتشار تدریجی CSP ارائه می‌کند؛ نمونه‌ها آموزشی‌اند و اعلام امنیت کامل هیچ وب‌سایتی نیستند.
برای شناخت دستورها از مرجع هدر CSP در MDN و برای مسیر طراحی از راهنمای CSP استفاده شده است. نکات مستند دربارهٔ سازوکار مرورگر از روش پیشنهادی استقرار در این نوشته جدا هستند. پیش از اعمال هر سیاست واقعی، وابستگی‌ها و رفتار صفحات همان پروژه را بررسی کنید.
۱. منابع واقعی صفحه و هدف سیاست را فهرست کنید
از چند مسیر نماینده شروع کنید: صفحهٔ اصلی، مقاله، فرم و بخشی که تعامل بیشتری دارد. مشخص کنید اسکریپت، سبک، فونت، تصویر و ارتباط شبکه از کدام مبدأ دریافت می‌شود. فهرست دامنه‌هایی که در تنظیمات قدیمی نوشته شده‌اند، جای بررسی درخواست واقعی مرورگر را نمی‌گیرد. افزونه یا کد تازه ممکن است وابستگی‌ای اضافه کرده باشد که در فهرست قبلی وجود ندارد.
هدف سیاست را نیز روشن بنویسید. کنترل منبع اسکریپت با محدود کردن قاب‌گذاری صفحه کار یکسانی نیست و دستورهای متفاوتی دارد. راهنمای MDN توضیح می‌دهد که CSP برای چند نوع محدودیت استفاده می‌شود. در پیشنهاد این مقاله، هر هدف به مسیرهای مورد بررسی و معیار موفقیت وصل می‌شود تا تیم بداند دقیقاً کدام رفتار را می‌خواهد محدود کند.
مالک هر وابستگی را پیدا کنید. اگر یک دامنه فقط به دلیل افزونه‌ای قدیمی دیده می‌شود، بررسی نیاز به آن می‌تواند از مجاز کردن دائمی‌اش مناسب‌تر باشد. این تصمیم را پس از شناخت کاربرد بگیرید؛ حذف منبع از فهرست بدون آزمایش ممکن است بخشی از خدمت را بشکند. در برگهٔ پیشنهادی، منبع، کاربرد، مالک و مسیر مصرف ثبت می‌شوند.
۲. محدودهٔ دستورها و کد درون‌صفحه را بررسی کنید
سیاست را به یک رشتهٔ طولانی مبهم تبدیل نکنید. هر دستور باید با نوع منبع و هدف معلوم ارتباط داشته باشد. برای مثال، مجاز بودن تصویر از یک مبدأ الزاماً همان مبدأ را برای اسکریپت مجاز نمی‌کند. در پیشنهاد طراحی، فهرست مورد نیاز هر دسته جدا نوشته می‌شود و رفتار پیش‌فرض دستورها نیز با مستندات بررسی می‌شود.
کد درون‌صفحه نیاز به تصمیم جدا دارد. افزودن مجوز گسترده صرفاً برای حذف خطای کنسول می‌تواند اثر هدف سیاست را کم کند. بسته به معماری، انتقال کد به فایل، استفاده از هش مناسب یا nonce می‌تواند مطرح شود. انتخاب باید با تولید صفحه و کش آن هماهنگ باشد. این مقاله دستور آمادهٔ تولید nonce ارائه نمی‌کند؛ تولید و قرار دادن صحیح آن بخشی از پیاده‌سازی سرور است.
اگر nonce استفاده می‌کنید، مسیر تغییر آن را از پاسخ تا عنصر مجاز بررسی کنید. یک مقدار ثابت که همیشه در همهٔ پاسخ‌ها تکرار می‌شود، با هدف مقدار تازهٔ غیرقابل پیش‌بینی سازگار نیست. کش صفحه نیز باید در این بررسی باشد تا هدر و محتوای پاسخ از دو نسخهٔ متفاوت نیایند. نمونهٔ آموزشی را بدون ارزیابی این وابستگی‌ها به تنظیم واقعی سایت منتقل نکنید.
۳. گزارش آزمایشی را از اعمال محدودیت جدا کنید
مرجع MDN برای حالت Report-Only توضیح می‌دهد که تخلف‌ها می‌توانند گزارش شوند بدون آنکه همان سیاست آزمایشی اجرا را مسدود کند. این حالت به بررسی اثر سیاست پیشنهادی کمک می‌کند، اما خودِ گزارش‌گیری معادل محافظت اجرایی نیست. در پیشنهاد استقرار، عنوان محیط و حالت سیاست در برگهٔ تغییر مشخص می‌شود تا تیم نتیجهٔ مشاهده را با فعال شدن محدودیت اشتباه نگیرد.
گزارش‌ها را با رفتار واقعی صفحه مقایسه کنید. یک تخلف ممکن است ناشی از منبع ضروری، افزونهٔ مرورگر، مسیر کم‌استفاده یا کد غیرمنتظره باشد. مجاز کردن خودکار همهٔ مبدأهای گزارش‌شده، مرحلهٔ بررسی را حذف می‌کند. پیشنهاد ما دسته‌بندی هر مورد با کاربرد و مالک است؛ منبع فقط پس از شناخت نیاز به فهرست مجاز افزوده شود.
مقصد گزارش نیز نیاز به کنترل دارد. محتوای گزارش می‌تواند شامل نشانی و جزئیات صفحه باشد، بنابراین محل نگهداری، دسترسی و حجم ورودی را بررسی کنید. دریافت تعداد زیاد رویداد نباید خدمت گزارش را بی‌دلیل سنگین کند. در طراحی پیشنهادی، دادهٔ لازم برای تحلیل نگه داشته می‌شود و اطلاعات غیرضروری حذف یا محدود می‌شوند.
۴. سیاست اجرایی را با مسیر بازگردانی منتشر کنید
پیش از اعمال سیاست، رفتار مورد انتظار چند تعامل ضروری را ثبت کنید. ارسال فرم، پیمایش مقاله، دریافت فونت و ارتباط لازم برنامه باید در آزمون وجود داشته باشند. صرف باز شدن صفحهٔ اصلی، سالم بودن همهٔ مسیرها را ثابت نمی‌کند. در محیط نماینده، هدر واقعی پاسخ را نیز بررسی کنید؛ تغییر فایل تنظیمات الزاماً به معنی دریافت همان هدر در مرورگر نیست.
مسیر بازگردانی مشخص باشد. اگر پس از انتشار بخشی از خدمت از کار افتاد، تیم باید نسخهٔ قبلی سیاست و روش اعمال آن را داشته باشد. پیشنهاد این مقاله، ثبت نسخهٔ هدر، زمان تغییر، مسیرهای آزموده‌شده و مسئول بررسی است. تغییر هم‌زمان افزونه، قالب و سیاست، نسبت دادن مشکل را دشوار می‌کند؛ تا حد ممکن دامنهٔ تغییر را قابل بررسی نگه دارید.
چند هدر یا چند سیاست نیز باید با هم بررسی شوند. اضافه کردن یک سیاست تازه همیشه محدودیت قبلی را خنثی نمی‌کند و ممکن است ترکیب آن‌ها سخت‌گیرانه‌تر شود. تنظیم وب‌سرور، برنامه و واسط توزیع محتوا را در فهرست محل‌های تولید هدر قرار دهید. وقتی رفتار مرورگر با انتظار تفاوت دارد، ابتدا پاسخ دریافت‌شده را مبنا بگیرید و سپس محل تنظیم را اصلاح کنید.
۵. تغییر وابستگی‌ها و مرز اثر CSP را بازبینی کنید
سیاست پس از انتشار به نگهداری نیاز دارد. افزوده شدن فونت، ابزار تحلیل یا قابلیت تازهٔ برنامه می‌تواند منبع جدیدی ایجاد کند. در مسیر پیشنهادی، تغییر وابستگی با فهرست منابع و آزمون تعامل همراه می‌شود. حذف یک قابلیت نیز فرصتی برای کاهش فهرست مجاز است؛ دامنه‌های بدون کاربرد نباید فقط به دلیل حضور تاریخی باقی بمانند.
CSP جای اعتبارسنجی ورودی، کنترل دسترسی یا مدیریت امن داده را نمی‌گیرد. یک سیاست مناسب می‌تواند بخشی از دفاع مرورگر باشد، اما دربارهٔ مجاز بودن مشاهدهٔ دادهٔ سرور تصمیم نمی‌گیرد. گزارش این مقاله باید محدودیت اثر را روشن کند و از عبارت‌هایی مانند امنیت کامل یا حذف همهٔ حمله‌ها پرهیز داشته باشد. نتیجهٔ بررسی باید به همان مسیر و همان نسخهٔ سیاست محدود بماند.
برای نگهداری، یک مجموعهٔ کوچک آزمون از مسیرهای مهم داشته باشید و پس از تغییر وابستگی دوباره اجرا کنید. گزارش کوتاه شامل هدف سیاست، منابع ضروری، حالت اجرایی، نتیجهٔ تعامل و محدودیت باقی‌مانده باشد. طراحی خوب CSP با شناخت رفتار واقعی سایت آغاز می‌شود و با بازبینی تغییرات ادامه می‌یابد؛ یک هدر کپی‌شده بدون این زمینه، تصمیم امنیتی کامل نیست.
منابع و مطالعهٔ بیشتر
بررسی منابع: ۲۲ مهر ۱۴۰۵. تحلیل‌ها و پیشنهادهای اجرایی، جمع‌بندی نویسنده‌اند.
