مقاوم‌سازی امنیت فرانت‌اند: سیاست امنیت محتوا (CSP) و CORS

در چشم‌انداز دیجیتال و متصل امروزی، امنیت فرانت‌اند از اهمیت بالایی برخوردار است. برنامه‌های وب به طور فزاینده‌ای هدف حملات پیچیده قرار می‌گیرند، که این امر اقدامات امنیتی قوی را ضروری می‌سازد. دو جزء حیاتی در یک معماری امن فرانت‌اند، سیاست امنیت محتوا (CSP) و اشتراک‌گذاری منابع بین مبدأیی (CORS) هستند. این راهنمای جامع نگاهی عمیق به این فناوری‌ها می‌اندازد و نمونه‌های عملی و بینش‌های کاربردی را برای کمک به شما در تقویت برنامه‌های وب خود در برابر تهدیدات مدرن ارائه می‌دهد.

سیاست امنیت محتوا (CSP) چیست؟

سیاست امنیت محتوا (CSP) یک لایه امنیتی اضافی است که به شناسایی و کاهش انواع خاصی از حملات، از جمله اسکریپت‌نویسی بین سایتی (XSS) و حملات تزریق داده کمک می‌کند. CSP با ارسال یک هدر پاسخ HTTP به نام Content-Security-Policy از سوی وب سرور به مرورگر پیاده‌سازی می‌شود. این هدر یک لیست سفید از منابعی را تعریف می‌کند که مرورگر مجاز به بارگیری منابع از آن‌ها است. با محدود کردن منابع محتوایی که یک مرورگر می‌تواند بارگیری کند، CSP کار را برای مهاجمان جهت تزریق کد مخرب به وب‌سایت شما به طور قابل توجهی دشوارتر می‌کند.

نحوه عملکرد CSP

CSP با دستور دادن به مرورگر برای بارگیری منابع (مانند اسکریپت‌ها، شیوه‌نامه‌ها، تصاویر، فونت‌ها) تنها از منابع تأیید شده کار می‌کند. این منابع در هدر CSP با استفاده از دستورالعمل‌ها (directives) مشخص می‌شوند. اگر مرورگر تلاش کند منبعی را از یک منبعی که به صراحت مجاز نیست بارگیری کند، درخواست را مسدود کرده و یک تخلف را گزارش می‌دهد.

دستورالعمل‌های CSP: یک نمای کلی جامع

دستورالعمل‌های CSP انواع منابعی را که می‌توان از منابع خاص بارگیری کرد، کنترل می‌کنند. در اینجا به برخی از مهم‌ترین دستورالعمل‌ها اشاره می‌کنیم:

• default-src: منبع پیش‌فرض را برای تمام انواع محتوا مشخص می‌کند. این یک دستورالعمل جایگزین است که زمانی اعمال می‌شود که دستورالعمل‌های خاص‌تر دیگر وجود نداشته باشند.
• script-src: منابعی را که اسکریپت‌ها می‌توانند از آن‌ها بارگیری شوند، مشخص می‌کند. این برای جلوگیری از حملات XSS حیاتی است.
• style-src: منابعی را که شیوه‌نامه‌ها می‌توانند از آن‌ها بارگیری شوند، مشخص می‌کند.
• img-src: منابعی را که تصاویر می‌توانند از آن‌ها بارگیری شوند، مشخص می‌کند.
• font-src: منابعی را که فونت‌ها می‌توانند از آن‌ها بارگیری شوند، مشخص می‌کند.
• media-src: منابعی را که صدا و ویدئو می‌توانند از آن‌ها بارگیری شوند، مشخص می‌کند.
• object-src: منابعی را که پلاگین‌ها (مانند Flash) می‌توانند از آن‌ها بارگیری شوند، مشخص می‌کند. این دستورالعمل به دلیل خطرات امنیتی ذاتی پلاگین‌ها، اغلب روی 'none' تنظیم می‌شود تا آن‌ها را به طور کامل غیرفعال کند.
• frame-src: منابعی را که فریم‌ها (مانند <iframe>) می‌توانند از آن‌ها بارگیری شوند، مشخص می‌کند.
• connect-src: URL‌هایی را مشخص می‌کند که عامل کاربر (user agent) می‌تواند با استفاده از رابط‌های اسکریپتی مانند XMLHttpRequest، WebSocket و EventSource به آن‌ها متصل شود.
• base-uri: URL‌هایی را که می‌توان در عنصر <base> یک سند استفاده کرد، مشخص می‌کند.
• form-action: URL‌هایی را که می‌توان ارسال‌های فرم را به آن‌ها فرستاد، مشخص می‌کند.
• upgrade-insecure-requests: به عامل کاربر دستور می‌دهد که به طور خودکار درخواست‌های ناامن (HTTP) را به درخواست‌های امن (HTTPS) ارتقا دهد.
• report-uri: یک URL را مشخص می‌کند که مرورگر باید گزارش‌های مربوط به تخلفات CSP را به آنجا ارسال کند. این دستورالعمل به نفع `report-to` منسوخ شده است.
• report-to: نام یک گروه گزارش‌دهی را که در هدر `Report-To` تعریف شده است، مشخص می‌کند، جایی که مرورگر باید گزارش‌های مربوط به تخلفات CSP را ارسال کند.

کلمات کلیدی لیست منبع CSP

درون دستورالعمل‌های CSP، می‌توانید از کلمات کلیدی لیست منبع برای تعریف منابع مجاز استفاده کنید. در اینجا برخی از کلمات کلیدی رایج آورده شده است:

• 'self': به منابعی از همان مبدأ (طرح و میزبان) سند اجازه می‌دهد.
• 'none': منابع را از همه مبدأها غیرمجاز می‌کند.
• 'unsafe-inline': اجازه استفاده از اسکریپت‌ها و استایل‌های درون‌خطی را می‌دهد (مانند تگ‌های <script> و ویژگی‌های style). با احتیاط بسیار زیاد استفاده کنید زیرا این کار به طور قابل توجهی حفاظت CSP در برابر XSS را تضعیف می‌کند.
• 'unsafe-eval': اجازه استفاده از توابع ارزیابی کد پویا مانند eval() و Function() را می‌دهد. با احتیاط بسیار زیاد استفاده کنید زیرا این کار خطرات امنیتی قابل توجهی را به همراه دارد.
• 'unsafe-hashes': به کنترل‌کننده‌های رویداد درون‌خطی خاص یا تگ‌های <style> که با یک هش مشخص مطابقت دارند، اجازه می‌دهد. به پشتیبانی مرورگر نیاز دارد. با احتیاط استفاده کنید.
• 'strict-dynamic': مشخص می‌کند که اعتمادی که به صراحت به یک اسکریپت موجود در نشانه‌گذاری داده شده (با همراهی یک nonce یا هش)، باید به تمام اسکریپت‌هایی که توسط آن اسکریپت ریشه بارگیری می‌شوند، منتقل شود.
• data: به data: URI‌ها اجازه می‌دهد (مانند تصاویر درون‌خطی کدگذاری شده به صورت base64). با احتیاط استفاده کنید.
• https:: اجازه می‌دهد منابع از طریق HTTPS از هر دامنه‌ای بارگیری شوند.
• [hostname]: به منابع از یک دامنه خاص (مانند example.com) اجازه می‌دهد. همچنین می‌توانید شماره پورت را مشخص کنید (مانند example.com:8080).
• [scheme]://[hostname]:[port]: یک URI کاملاً واجد شرایط که به منابع از طرح، میزبان و پورت مشخص شده اجازه می‌دهد.

نمونه‌های عملی CSP

بیایید به چند نمونه عملی از هدرهای CSP نگاهی بیندازیم:

مثال ۱: CSP پایه با 'self'

این سیاست فقط به منابع از همان مبدأ اجازه می‌دهد:

            Content-Security-Policy: default-src 'self'
            

              
                Copy
              
            
          

مثال ۲: اجازه دادن به اسکریپت‌ها از یک دامنه خاص

این سیاست به اسکریپت‌ها از دامنه خودتان و یک CDN مورد اعتماد اجازه می‌دهد:

            Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com
            

              
                Copy
              
            
          

مثال ۳: غیرفعال کردن اسکریپت‌ها و استایل‌های درون‌خطی

این سیاست اسکریپت‌ها و استایل‌های درون‌خطی را غیرمجاز می‌کند، که یک دفاع قوی در برابر XSS است:

            Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self'
            

              
                Copy
              
            
          

مهم: غیرفعال کردن اسکریپت‌های درون‌خطی نیازمند بازآرایی (refactoring) HTML شما برای انتقال اسکریپت‌های درون‌خطی به فایل‌های خارجی است.

مثال ۴: استفاده از Nonce برای اسکریپت‌های درون‌خطی

اگر مجبور به استفاده از اسکریپت‌های درون‌خطی هستید، از nonce‌ها (توکن‌های یک‌بار مصرف و تصادفی رمزنگاری شده) برای قرار دادن بلوک‌های اسکریپت درون‌خطی خاص در لیست سفید استفاده کنید. این روش امن‌تر از 'unsafe-inline' است. سرور باید برای هر درخواست یک nonce منحصر به فرد ایجاد کند و آن را هم در هدر CSP و هم در تگ <script> قرار دهد.

            Content-Security-Policy: default-src 'self'; script-src 'nonce-r4nd0mN0nc3'; style-src 'self'
            

              
                Copy
              
            
          

            <script nonce="r4nd0mN0nc3"> console.log('Inline script'); </script>
            

              
                Copy
              
            
          

توجه: به یاد داشته باشید که برای هر درخواست یک nonce جدید ایجاد کنید. از nonce‌ها مجدداً استفاده نکنید!

مثال ۵: استفاده از هش برای استایل‌های درون‌خطی

مشابه nonce‌ها، می‌توان از هش‌ها برای قرار دادن بلوک‌های <style> درون‌خطی خاص در لیست سفید استفاده کرد. این کار با تولید یک هش SHA256، SHA384 یا SHA512 از محتوای استایل انجام می‌شود.

            Content-Security-Policy: default-src 'self'; style-src 'sha256-HASHEDSTYLES'
            

              
                Copy
              
            
          

            <style sha256="HASHEDSTYLES"> body { background-color: #f0f0f0; } </style>
            

              
                Copy
              
            
          

توجه: هش‌ها نسبت به nonce‌ها انعطاف‌پذیری کمتری دارند زیرا هر تغییری در محتوای استایل، هش را باطل می‌کند.

مثال ۶: گزارش تخلفات CSP

برای نظارت بر تخلفات CSP، از دستورالعمل report-uri یا report-to استفاده کنید:

            Content-Security-Policy: default-src 'self'; report-to csp-endpoint;
            

              
                Copy
              
            
          

شما همچنین باید هدر Report-To را پیکربندی کنید. هدر Report-To یک یا چند گروه گزارش‌دهی را تعریف می‌کند که مشخص می‌کنند گزارش‌ها باید کجا و چگونه ارسال شوند.

            Report-To: {"group":"csp-endpoint","max_age":10886400,"endpoints":[{"url":"https://example.com/csp-report"}]}
            

              
                Copy
              
            
          

تست و استقرار CSP

پیاده‌سازی CSP نیازمند برنامه‌ریزی و تست دقیق است. با یک سیاست محدودکننده شروع کنید و به تدریج در صورت نیاز آن را بازتر کنید. از هدر Content-Security-Policy-Report-Only برای تست سیاست خود بدون مسدود کردن منابع استفاده کنید. این هدر تخلفات را بدون اجرای سیاست گزارش می‌دهد و به شما امکان می‌دهد مشکلات را قبل از استقرار سیاست در محیط تولید شناسایی و رفع کنید.

            Content-Security-Policy-Report-Only: default-src 'self'; report-to csp-endpoint;
            

              
                Copy
              
            
          

گزارش‌های تولید شده توسط مرورگر را برای شناسایی هرگونه تخلف تحلیل کرده و سیاست خود را بر اساس آن تنظیم کنید. هنگامی که مطمئن شدید سیاست شما به درستی کار می‌کند، آن را با استفاده از هدر Content-Security-Policy مستقر کنید.

بهترین شیوه‌ها برای CSP

• با default-src شروع کنید: همیشه یک default-src تعریف کنید تا یک سیاست پایه ایجاد شود.
• دقیق باشید: از دستورالعمل‌ها و کلمات کلیدی لیست منبع خاص برای محدود کردن دامنه سیاست خود استفاده کنید.
• از 'unsafe-inline' و 'unsafe-eval' اجتناب کنید: این کلمات کلیدی به طور قابل توجهی CSP را تضعیف می‌کنند و باید تا حد امکان از آن‌ها اجتناب شود.
• برای اسکریپت‌ها و استایل‌های درون‌خطی از nonce یا هش استفاده کنید: اگر مجبور به استفاده از اسکریپت‌ها یا استایل‌های درون‌خطی هستید، از nonce یا هش برای قرار دادن بلوک‌های کد خاص در لیست سفید استفاده کنید.
• تخلفات CSP را نظارت کنید: از دستورالعمل report-uri یا report-to برای نظارت بر تخلفات CSP و تنظیم سیاست خود بر اساس آن استفاده کنید.
• به طور کامل تست کنید: از هدر Content-Security-Policy-Report-Only برای تست سیاست خود قبل از استقرار آن در محیط تولید استفاده کنید.
• تکرار و اصلاح کنید: CSP یک پیکربندی یک‌باره نیست. به طور مداوم سیاست خود را برای انطباق با تغییرات در برنامه و چشم‌انداز تهدیدات نظارت و اصلاح کنید.

اشتراک‌گذاری منابع بین مبدأیی (CORS) چیست؟

اشتراک‌گذاری منابع بین مبدأیی (CORS) مکانیزمی است که به صفحات وب از یک مبدأ (دامنه) اجازه می‌دهد تا به منابعی از یک مبدأ متفاوت دسترسی پیدا کنند. به طور پیش‌فرض، مرورگرها یک سیاست همان مبدأ (Same-Origin Policy) را اعمال می‌کنند که از ارسال درخواست اسکریپت‌ها به مبدأیی متفاوت از مبدأیی که اسکریپت از آنجا نشأت گرفته، جلوگیری می‌کند. CORS راهی برای برداشتن انتخابی این محدودیت فراهم می‌کند، به طوری که درخواست‌های قانونی بین مبدأیی مجاز شمرده شده و در عین حال از حملات مخرب محافظت می‌شود.

درک سیاست همان مبدأ (Same-Origin Policy)

سیاست همان مبدأ یک مکانیزم امنیتی بنیادی است که از دسترسی یک اسکریپت مخرب از یک وب‌سایت به داده‌های حساس در وب‌سایت دیگر جلوگیری می‌کند. یک مبدأ توسط طرح (پروتکل)، میزبان (دامنه) و پورت تعریف می‌شود. دو URL تنها و تنها در صورتی دارای مبدأ یکسان هستند که طرح، میزبان و پورت یکسانی داشته باشند.

برای مثال:

• https://www.example.com/app1/index.html و https://www.example.com/app2/index.html دارای مبدأ یکسان هستند.
• https://www.example.com/index.html و http://www.example.com/index.html دارای مبدأهای متفاوت هستند (طرح متفاوت).
• https://www.example.com/index.html و https://sub.example.com/index.html دارای مبدأهای متفاوت هستند (میزبان متفاوت).
• https://www.example.com:8080/index.html و https://www.example.com:80/index.html دارای مبدأهای متفاوت هستند (پورت متفاوت).

نحوه عملکرد CORS

هنگامی که یک صفحه وب یک درخواست بین مبدأیی ارسال می‌کند، مرورگر ابتدا یک درخواست "preflight" به سرور می‌فرستد. درخواست preflight از متد HTTP OPTIONS استفاده می‌کند و شامل هدرهایی است که متد HTTP و هدرهایی را که درخواست واقعی استفاده خواهد کرد، نشان می‌دهد. سپس سرور با هدرهایی پاسخ می‌دهد که نشان می‌دهد آیا درخواست بین مبدأیی مجاز است یا خیر.

اگر سرور درخواست را مجاز بداند، هدر Access-Control-Allow-Origin را در پاسخ خود قرار می‌دهد. این هدر مبدأ(های) مجاز برای دسترسی به منبع را مشخص می‌کند. سپس مرورگر با درخواست واقعی ادامه می‌دهد. اگر سرور درخواست را مجاز نداند، هدر Access-Control-Allow-Origin را قرار نمی‌دهد و مرورگر درخواست را مسدود می‌کند.

هدرهای CORS: نگاهی دقیق

CORS برای ارتباط بین مرورگر و سرور به هدرهای HTTP متکی است. در اینجا هدرهای کلیدی CORS آورده شده است:

• Access-Control-Allow-Origin: مبدأ(های) مجاز برای دسترسی به منبع را مشخص می‌کند. این هدر می‌تواند شامل یک مبدأ خاص (مانند https://www.example.com)، یک علامت wildcard (*)، یا null باشد. استفاده از * به درخواست‌ها از هر مبدأیی اجازه می‌دهد، که به دلایل امنیتی به طور کلی توصیه نمی‌شود. استفاده از `null` تنها برای "پاسخ‌های مات" مناسب است، مانند زمانی که منبع با استفاده از پروتکل `file://` یا یک data URI بازیابی می‌شود.
• Access-Control-Allow-Methods: متدهای HTTP مجاز برای درخواست بین مبدأیی را مشخص می‌کند (مانند GET, POST, PUT, DELETE).
• Access-Control-Allow-Headers: هدرهای HTTP مجاز در درخواست بین مبدأیی را مشخص می‌کند. این برای مدیریت هدرهای سفارشی مهم است.
• Access-Control-Allow-Credentials: نشان می‌دهد که آیا مرورگر باید اعتبارنامه‌ها (مانند کوکی‌ها، هدرهای احراز هویت) را در درخواست بین مبدأیی قرار دهد یا خیر. این هدر باید روی true تنظیم شود تا اعتبارنامه‌ها مجاز باشند.
• Access-Control-Expose-Headers: مشخص می‌کند کدام هدرها می‌توانند برای کلاینت قابل مشاهده باشند. به طور پیش‌فرض، تنها مجموعه محدودی از هدرها قابل مشاهده هستند.
• Access-Control-Max-Age: حداکثر زمانی (بر حسب ثانیه) را که مرورگر می‌تواند درخواست preflight را کش کند، مشخص می‌کند.
• Origin: این یک هدر درخواست است که توسط مرورگر ارسال می‌شود تا مبدأ درخواست را نشان دهد.
• Vary: یک هدر عمومی HTTP، اما برای CORS مهم است. هنگامی که Access-Control-Allow-Origin به صورت پویا تولید می‌شود، هدر Vary: Origin باید در پاسخ گنجانده شود تا به مکانیزم‌های کش اطلاع دهد که پاسخ بر اساس هدر درخواست Origin متغیر است.

نمونه‌های عملی CORS

بیایید به چند نمونه عملی از پیکربندی‌های CORS نگاهی بیندازیم:

مثال ۱: اجازه دادن به درخواست‌ها از یک مبدأ خاص

این پیکربندی فقط به درخواست‌ها از https://www.example.com اجازه می‌دهد:

            Access-Control-Allow-Origin: https://www.example.com
            

              
                Copy
              
            
          

مثال ۲: اجازه دادن به درخواست‌ها از هر مبدأیی (توصیه نمی‌شود)

این پیکربندی به درخواست‌ها از هر مبدأیی اجازه می‌دهد. با احتیاط استفاده کنید زیرا می‌تواند خطرات امنیتی به همراه داشته باشد:

            Access-Control-Allow-Origin: *
            

              
                Copy
              
            
          

مثال ۳: اجازه دادن به متدها و هدرهای خاص

این پیکربندی به متدهای GET، POST و PUT و هدرهای Content-Type و Authorization اجازه می‌دهد:

            Access-Control-Allow-Origin: https://www.example.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: Content-Type, Authorization
            

              
                Copy
              
            
          

مثال ۴: اجازه دادن به اعتبارنامه‌ها

برای اجازه دادن به اعتبارنامه‌ها (مانند کوکی‌ها)، باید Access-Control-Allow-Credentials را روی true تنظیم کنید و یک مبدأ خاص را مشخص کنید (هنگام اجازه دادن به اعتبارنامه‌ها نمی‌توانید از * استفاده کنید):

            Access-Control-Allow-Origin: https://www.example.com
Access-Control-Allow-Credentials: true
            

              
                Copy
              
            
          

شما همچنین باید credentials: 'include' را در درخواست JavaScript fetch/XMLHttpRequest خود تنظیم کنید.

            fetch('https://api.example.com/data', {
  credentials: 'include'
})
            

              
                Copy
              
            
          

درخواست‌های Preflight در CORS

برای انواع خاصی از درخواست‌های بین مبدأیی (مانند درخواست‌ها با هدرهای سفارشی یا متدهایی غیر از GET، HEAD یا POST با Content-Type از نوع application/x-www-form-urlencoded، multipart/form-data یا text/plain)، مرورگر یک درخواست preflight با استفاده از متد OPTIONS ارسال می‌کند. سرور باید به درخواست preflight با هدرهای CORS مناسب پاسخ دهد تا نشان دهد آیا درخواست واقعی مجاز است یا خیر.

در اینجا نمونه‌ای از یک درخواست و پاسخ preflight آورده شده است:

درخواست Preflight (OPTIONS):

            OPTIONS /data HTTP/1.1
Origin: https://www.example.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: Content-Type, Authorization
            

              
                Copy
              
            
          

پاسخ Preflight (200 OK):

            HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://www.example.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Max-Age: 86400
            

              
                Copy
              
            
          

هدر Access-Control-Max-Age مشخص می‌کند که مرورگر چه مدت می‌تواند پاسخ preflight را کش کند، که این امر تعداد درخواست‌های preflight را کاهش می‌دهد.

CORS و JSONP

JSON with Padding (JSONP) یک تکنیک قدیمی‌تر برای دور زدن سیاست همان مبدأ است. با این حال، JSONP خطرات امنیتی قابل توجهی دارد و باید به نفع CORS از آن اجتناب شود. JSONP به تزریق تگ‌های <script> به صفحه متکی است که می‌تواند کد دلخواه را اجرا کند. CORS راهی امن‌تر و انعطاف‌پذیرتر برای مدیریت درخواست‌های بین مبدأیی فراهم می‌کند.

بهترین شیوه‌ها برای CORS

• از استفاده از * اجتناب کنید: از استفاده از wildcard (*) در هدر Access-Control-Allow-Origin خودداری کنید، زیرا به درخواست‌ها از هر مبدأیی اجازه می‌دهد. به جای آن، مبدأ(های) خاصی را که مجاز به دسترسی به منبع هستند، مشخص کنید.
• در مورد متدها و هدرها دقیق باشید: متدها و هدرهای HTTP دقیقی را که در هدرهای Access-Control-Allow-Methods و Access-Control-Allow-Headers مجاز هستند، مشخص کنید.
• با احتیاط از Access-Control-Allow-Credentials استفاده کنید: تنها در صورتی که نیاز به اجازه دادن به اعتبارنامه‌ها (مانند کوکی‌ها) در درخواست‌های بین مبدأیی دارید، Access-Control-Allow-Credentials را فعال کنید. از پیامدهای امنیتی اجازه دادن به اعتبارنامه‌ها آگاه باشید.
• درخواست‌های preflight خود را ایمن کنید: اطمینان حاصل کنید که سرور شما به درستی درخواست‌های preflight را مدیریت می‌کند و هدرهای CORS صحیح را برمی‌گرداند.
• از HTTPS استفاده کنید: همیشه برای هر دو مبدأ و منابعی که به صورت بین مبدأیی به آن‌ها دسترسی پیدا می‌کنید، از HTTPS استفاده کنید. این به محافظت در برابر حملات مرد میانی (man-in-the-middle) کمک می‌کند.
• Vary: Origin: اگر به صورت پویا هدر `Access-Control-Allow-Origin` را تولید می‌کنید، همیشه هدر `Vary: Origin` را برای جلوگیری از مشکلات کش اضافه کنید.

CSP و CORS در عمل: یک رویکرد ترکیبی

در حالی که هم CSP و هم CORS به نگرانی‌های امنیتی می‌پردازند، آن‌ها در لایه‌های مختلفی عمل می‌کنند و حفاظت مکملی را ارائه می‌دهند. CSP بر جلوگیری از بارگیری محتوای مخرب توسط مرورگر تمرکز دارد، در حالی که CORS بر کنترل اینکه کدام مبدأها می‌توانند به منابع روی سرور شما دسترسی داشته باشند، تمرکز دارد.

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

مثال: ایمن‌سازی یک API با CSP و CORS

فرض کنید شما یک API در آدرس https://api.example.com دارید که می‌خواهید فقط از https://www.example.com قابل دسترسی باشد. می‌توانید سرور خود را طوری پیکربندی کنید که هدرهای زیر را برگرداند:

هدرهای پاسخ API (https://api.example.com):

            Access-Control-Allow-Origin: https://www.example.com
Content-Type: application/json
            

              
                Copy
              
            
          

و می‌توانید وب‌سایت خود (https://www.example.com) را برای استفاده از هدر CSP زیر پیکربندی کنید:

هدر CSP وب‌سایت (https://www.example.com):

            Content-Security-Policy: default-src 'self'; script-src 'self'; connect-src 'self' https://api.example.com;
            

              
                Copy
              
            
          

این سیاست CSP به وب‌سایت اجازه می‌دهد تا اسکریپت‌ها را بارگیری کرده و به API متصل شود، اما از بارگیری اسکریپت‌ها یا اتصال به دامنه‌های دیگر جلوگیری می‌کند.

نتیجه‌گیری

سیاست امنیت محتوا (CSP) و اشتراک‌گذاری منابع بین مبدأیی (CORS) ابزارهای ضروری برای مقاوم‌سازی امنیت برنامه‌های فرانت‌اند شما هستند. با پیکربندی دقیق CSP و CORS، می‌توانید به طور قابل توجهی خطر حملات XSS، حملات تزریق داده و سایر آسیب‌پذیری‌های امنیتی را کاهش دهید. به یاد داشته باشید که با یک سیاست محدودکننده شروع کنید، به طور کامل تست کنید و به طور مداوم پیکربندی خود را برای انطباق با تغییرات در برنامه و چشم‌انداز تهدیدات در حال تحول، نظارت و اصلاح کنید. با اولویت قرار دادن امنیت فرانت‌اند، می‌توانید از کاربران خود محافظت کرده و یکپارچگی برنامه‌های وب خود را در دنیای دیجیتال پیچیده امروزی تضمین کنید.