
CSP یا Content Security Policy سیاستی است که به مرورگر میگوید کدها و منابع سایت از چه مبداهایی مجازند؛ این فناوری به کاهش ریسک XSS کمک میکند اما جایگزین output encoding و sanitization نیست.


CSP چیست و چه مسئلهای را حل میکند؟
سیاست امنیت محتوای وب یا Content Security Policy (CSP) مجموعهای از قواعد است که به مرورگر میگوید کد و منابع یک سایت از کجا میتوانند بارگذاری شوند و چه کاری اجازهٔ اجرا دارند. هدف اصلی آن کاهش ریسک حملههای XSS است؛ یعنی حالتی که ورودی کنترلنشدهٔ مهاجم بهعنوان JavaScript در مرورگر بازدیدکننده اجرا میشود. CSP یک لایهٔ دفاعی مهم است، اما جایگزین output encoding، اعتبارسنجی ورودی و sanitization نیست.
در وردپرس، فعالسازی ناگهانی CSP میتواند اسکریپتهای قالب، افزونهها، درگاه پرداخت، ابزارهای آمارگیری و سرویسهای ثالث را از کار بیندازد. راه امن، اجرای تدریجی و قابلاندازهگیری است؛ نه قراردادن یک allowlist طولانی و رهاکردن آن بدون پایش. در نتیجه، این سیاست باید بخشی از فرایند انتشار باشد، نه یک تغییر اضطراری روی سایت زنده. برای آشنایی با آموزشهای فنی بیشتر میتوانید به مجلهٔ آموزشی تکتاز سر بزنید.
مرحلهٔ اول: فهرستبرداری و اجرای Report-Only
ابتدا تمام منابع صفحه را در محیط staging فهرست کنید: اسکریپتهای هستهٔ وردپرس، قالب، افزونهها، CDN، فونتها، iframeها، درخواستهای AJAX و سرویسهای پرداخت. سپس بهجای مسدودسازی واقعی، هدر Content-Security-Policy-Report-Only را اضافه کنید. این حالت policy را گزارش میکند، اما بارگذاری را متوقف نمیکند؛ بنابراین میتوان مسیرهای لازم را پیش از ایجاد اختلال شناسایی کرد.
گزارشهای violation را در یک endpoint اختصاصی جمع کنید و آنها را بر اساس صفحه، directive، منبع و تعداد تکرار دستهبندی کنید. report-to روش ترجیحی جدیدتر است، ولی برای سازگاری مرورگرها پشتیبانی از report-uri نیز ممکن است لازم باشد. گزارشها را بدون ذخیرهٔ دادههای شخصی غیرضروری نگه دارید و برای endpoint گزارشگیری rate limit در نظر بگیرید. این مرحله کمک میکند سیاست امنیتی قبل از enforce با دادهٔ واقعی همان قالب و افزونهها تنظیم شود.
مرحلهٔ دوم: حذف الگوهای ناامن
موارد unsafe-inline و unsafe-eval را بهعنوان بدهی فنی در نظر بگیرید. handlerهای inline مانند onclick را به listenerهای جاوااسکریپتی منتقل کنید و کدهایی را که به eval() یا سازوکارهای مشابه وابستهاند بازنویسی کنید. در صورت نیاز به اسکریپت پویا، برای هر پاسخ یک nonce تصادفی و غیرقابلحدس بسازید و آن را فقط به تگهای script مجاز همان پاسخ بدهید؛ nonce نباید ثابت، قابل پیشبینی یا در چند درخواست تکراری باشد.
برای فایلهای ایستا میتوان از hash استفاده کرد. اگر یک اسکریپت مجاز، اسکریپت ثالث دیگری را بارگذاری میکند، strict-dynamic میتواند اعتماد را به زنجیرهٔ کنترلشده منتقل کند؛ بااینحال باید رفتار واقعی آن را در مرورگرهای هدف تست کرد. همچنین در سایتهایی که به object embed نیاز ندارند، object-src 'none' یک محدودکنندهٔ مناسب است.
مرحلهٔ سوم: تست وردپرس و تبدیل به Enforce
در staging، ورود و خروج کاربران، فرمها، ویرایشگر، checkout، پرداخت، کش، بارگذاری رسانه، REST API و صفحات دارای اسکریپت ثالث را تست کنید. قبل از enforce، policy را روی چند صفحهٔ پرترافیک با گزارشگیری فعال اجرا کنید و هر exception را مستند کنید. برای منابع ضروری، مبدا دقیق و کمینه را مشخص کنید؛ از مجازکردن دامنههای بزرگ یا * برای رفع سریع خطا پرهیز کنید.
پس از پایدارشدن گزارشها، policy را به Content-Security-Policy تبدیل کنید و پایش را ادامه دهید. تغییرات افزونه یا قالب، اضافهشدن ابزار بازاریابی و تغییر درگاه پرداخت میتواند violation تازه ایجاد کند. هر بهروزرسانی مهم را ابتدا در staging و سپس با rollout مرحلهای منتشر کنید. در سایتهای پرترافیک، اجرای تدریجی CSP در وردپرس امکان مقایسهٔ نرخ خطا، تکمیل خرید و رفتار کاربران را فراهم میکند و تصمیم امنیتی را از حدسزدن جدا نگه میدارد.
چکلیست عملی مدیر سایت
۱. نسخهٔ پشتیبان و محیط staging آماده باشد. ۲. منابع و اسکریپتهای واقعی فهرست شوند. ۳. Report-Only و endpoint گزارشگیری فعال شود. ۴. inline JavaScript و eval() بهتدریج حذف شوند. ۵. nonce یا hash با پیادهسازی واقعی قالب استفاده شود. ۶. صفحات ورود، فرم، پرداخت و پنل تست شوند. ۷. policy کمینه به enforce تبدیل شود و گزارشهای پس از انتشار پایش شوند.
برای جزئیات directiveها و ترتیب پیادهسازی، راهنمای CSP در MDN منبع اصلی این آموزش است. نمونههای وردپرسی را همیشه با توجه به افزونهها و سرویسهای واقعی همان سایت تنظیم کنید؛ CSP نسخهٔ آماده و یکسانی برای همهٔ نصبها ندارد.












