۲۷ مرداد ۱۴۰۴فارسی

راهنمای جامع برای پیشگیری از حملات اسکریپت‌نویسی بین‌سایتی (XSS) و پیاده‌سازی سیاست امنیت محتوا (CSP) برای امنیت قوی فرانت‌اند.

امنیت فرانت‌اند: پیشگیری از XSS و سیاست امنیت محتوا (CSP)

در چشم‌انداز توسعه وب امروزی، امنیت فرانت‌اند از اهمیت بالایی برخوردار است. با پیچیده‌تر و تعاملی‌تر شدن برنامه‌های وب، آسیب‌پذیری آن‌ها در برابر حملات مختلف، به‌ویژه اسکریپت‌نویسی بین‌سایتی (XSS)، نیز افزایش می‌یابد. این مقاله یک راهنمای جامع برای درک و کاهش آسیب‌پذیری‌های XSS و همچنین پیاده‌سازی سیاست امنیت محتوا (CSP) به عنوان یک مکانیسم دفاعی قوی ارائه می‌دهد.

درک اسکریپت‌نویسی بین‌سایتی (XSS)

XSS چیست؟

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

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

انواع حملات XSS

XSS بازتابی (Reflected): اسکریپت مخرب به یک درخواست واحد تزریق می‌شود. سرور داده‌های تزریق شده را از درخواست HTTP می‌خواند و آن را به کاربر بازتاب می‌دهد و اسکریپت در مرورگر او اجرا می‌شود. این کار اغلب از طریق ایمیل‌های فیشینگ حاوی لینک‌های مخرب انجام می‌شود.
XSS ذخیره شده (Stored): اسکریپت مخرب روی سرور هدف ذخیره می‌شود (مثلاً در یک پایگاه داده، پست انجمن یا بخش نظرات). وقتی کاربران دیگر به داده‌های ذخیره شده دسترسی پیدا می‌کنند، اسکریپت در مرورگرهای آن‌ها اجرا می‌شود. این نوع XSS به ویژه خطرناک است زیرا می‌تواند تعداد زیادی از کاربران را تحت تأثیر قرار دهد.
XSS مبتنی بر DOM: آسیب‌پذیری در خود کد جاوا اسکریپت سمت کلاینت وجود دارد. این حمله DOM (Document Object Model) را در مرورگر قربانی دستکاری می‌کند و باعث اجرای اسکریپت مخرب می‌شود. این اغلب شامل دستکاری URLها یا سایر داده‌های سمت کلاینت است.

تأثیر XSS

عواقب یک حمله موفق XSS می‌تواند شدید باشد:

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

تکنیک‌های پیشگیری از XSS

پیشگیری از حملات XSS نیازمند یک رویکرد چندلایه است که بر اعتبارسنجی ورودی و کدگذاری خروجی تمرکز دارد.

اعتبارسنجی ورودی

اعتبارسنجی ورودی فرآیند تأیید انطباق ورودی کاربر با فرمت و نوع داده مورد انتظار است. اگرچه این یک دفاع کامل در برابر XSS نیست، اما به کاهش سطح حمله کمک می‌کند.

اعتبارسنجی لیست سفید (Whitelist): مجموعه‌ای دقیق از کاراکترها و الگوهای مجاز را تعریف کنید. هر ورودی‌ای که با لیست سفید مطابقت ندارد را رد کنید. برای مثال، اگر انتظار دارید کاربر نامی را وارد کند، فقط به حروف، فاصله‌ها و احتمالاً خط تیره اجازه دهید.
اعتبارسنجی لیست سیاه (Blacklist): کاراکترها یا الگوهای مخرب شناخته شده را شناسایی و مسدود کنید. با این حال، لیست‌های سیاه اغلب ناقص هستند و می‌توانند توسط مهاجمان هوشمند دور زده شوند. اعتبارسنجی لیست سفید به طور کلی بر اعتبارسنجی لیست سیاه ترجیح داده می‌شود.
اعتبارسنجی نوع داده: اطمینان حاصل کنید که ورودی با نوع داده مورد انتظار مطابقت دارد (مثلاً عدد صحیح، آدرس ایمیل، URL).
محدودیت طول: برای جلوگیری از آسیب‌پذیری‌های سرریز بافر، محدودیت‌های حداکثر طول را بر روی فیلدهای ورودی اعمال کنید.

مثال (PHP):


<?php
$username = $_POST['username'];

// اعتبارسنجی لیست سفید: فقط به کاراکترهای الفبایی-عددی و آندرلاین اجازه داده می‌شود
if (preg_match('/^[a-zA-Z0-9_]+$/', $username)) {
  // نام کاربری معتبر
  echo "نام کاربری معتبر: " . htmlspecialchars($username, ENT_QUOTES, 'UTF-8');
} else {
  // نام کاربری نامعتبر
  echo "نام کاربری نامعتبر. فقط کاراکترهای الفبایی-عددی و آندرلاین مجاز هستند.";
}
?>

کدگذاری خروجی (Escaping)

کدگذاری خروجی، که به عنوان escaping نیز شناخته می‌شود، فرآیند تبدیل کاراکترهای خاص به معادل‌های موجودیت HTML یا کدگذاری شده در URL است. این کار از تفسیر کاراکترها به عنوان کد توسط مرورگر جلوگیری می‌کند.

کدگذاری HTML: کاراکترهایی که در HTML معنای خاصی دارند، مانند <، >، &، " و ' را escape کنید. از توابعی مانند htmlspecialchars() در PHP یا متدهای معادل در زبان‌های دیگر استفاده کنید.
کدگذاری URL: کاراکترهایی که در URLها معنای خاصی دارند، مانند فاصله‌ها، اسلش‌ها و علامت‌های سوال را کدگذاری کنید. از توابعی مانند urlencode() در PHP یا متدهای معادل در زبان‌های دیگر استفاده کنید.
کدگذاری جاوا اسکریپت: کاراکترهایی که در جاوا اسکریپت معنای خاصی دارند، مانند کوتیشن تکی، کوتیشن دوتایی و بک‌اسلش را escape کنید. از توابعی مانند JSON.stringify() یا کتابخانه‌هایی مانند ESAPI (Encoder) استفاده کنید.

مثال (جاوا اسکریپت - کدگذاری HTML):


function escapeHTML(str) {
  let div = document.createElement('div');
  div.appendChild(document.createTextNode(str));
  return div.innerHTML;
}

let userInput = '<script>alert("XSS");</script>';
let encodedInput = escapeHTML(userInput);

// خروجی کدگذاری شده را در DOM قرار دهید
document.getElementById('output').innerHTML = encodedInput; // Output: &lt;script&gt;alert("XSS");&lt;/script&gt;

مثال (پایتون - کدگذاری HTML):


import html

user_input = '<script>alert("XSS");</script>'
encoded_input = html.escape(user_input)

print(encoded_input) # Output: &lt;script&gt;alert("XSS");&lt;/script&gt;

کدگذاری آگاه از زمینه (Context-Aware)

نوع کدگذاری که استفاده می‌کنید به زمینه‌ای که داده در آن نمایش داده می‌شود بستگی دارد. برای مثال، اگر داده را درون یک ویژگی HTML نمایش می‌دهید، باید از کدگذاری ویژگی HTML استفاده کنید. اگر داده را درون یک رشته جاوا اسکریپت نمایش می‌دهید، باید از کدگذاری رشته جاوا اسکریپت استفاده کنید.

مثال:


<input type="text" value="<?php echo htmlspecialchars($_GET['name'], ENT_QUOTES, 'UTF-8'); ?>">

در این مثال، مقدار پارامتر name از URL درون ویژگی value یک فیلد ورودی نمایش داده می‌شود. تابع htmlspecialchars() تضمین می‌کند که هر کاراکتر خاصی در پارامتر name به درستی کدگذاری شده و از حملات XSS جلوگیری می‌کند.

استفاده از موتور قالب (Template Engine)

بسیاری از فریم‌ورک‌های وب مدرن و موتورهای قالب (مانند React, Angular, Vue.js, Twig, Jinja2) مکانیسم‌های کدگذاری خروجی خودکار را فراهم می‌کنند. این موتورها به طور خودکار متغیرها را هنگام رندر شدن در قالب‌ها escape می‌کنند و خطر آسیب‌پذیری‌های XSS را کاهش می‌دهند. همیشه از ویژگی‌های escaping داخلی موتور قالب خود استفاده کنید.

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

CSP چیست؟

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

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

CSP چگونه کار می‌کند

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

مثال هدر CSP:


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

این هدر سیاست‌های زیر را تعریف می‌کند:

default-src 'self': اجازه می‌دهد منابع فقط از همان مبدأ (دامنه) صفحه وب بارگذاری شوند.
script-src 'self' https://example.com: اجازه می‌دهد جاوا اسکریپت از همان مبدأ و از https://example.com بارگذاری شود.
style-src 'self' https://cdn.example.com: اجازه می‌دهد CSS از همان مبدأ و از https://cdn.example.com بارگذاری شود.
img-src 'self' data:: اجازه می‌دهد تصاویر از همان مبدأ و از data URIها (تصاویر کدگذاری شده با base64) بارگذاری شوند.
font-src 'self': اجازه می‌دهد فونت‌ها از همان مبدأ بارگذاری شوند.

دستورالعمل‌های CSP

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

default-src: سیاست پیش‌فرض را برای همه انواع منابع تنظیم می‌کند.
script-src: منابعی که جاوا اسکریپت می‌تواند از آن‌ها بارگذاری شود را تعریف می‌کند.
style-src: منابعی که CSS می‌تواند از آن‌ها بارگذاری شود را تعریف می‌کند.
img-src: منابعی که تصاویر می‌توانند از آن‌ها بارگذاری شوند را تعریف می‌کند.
font-src: منابعی که فونت‌ها می‌توانند از آن‌ها بارگذاری شوند را تعریف می‌کند.
connect-src: مبدأهایی که کلاینت می‌تواند به آن‌ها متصل شود را تعریف می‌کند (مثلاً از طریق WebSockets, XMLHttpRequest).
media-src: منابعی که صدا و ویدیو می‌توانند از آن‌ها بارگذاری شوند را تعریف می‌کند.
object-src: منابعی که پلاگین‌ها (مانند Flash) می‌توانند از آن‌ها بارگذاری شوند را تعریف می‌کند.
frame-src: مبدأهایی که می‌توانند به عنوان فریم (<frame>، <iframe>) جاسازی شوند را تعریف می‌کند.
base-uri: URLهایی که می‌توانند در عنصر <base> یک سند استفاده شوند را محدود می‌کند.
form-action: URLهایی که فرم‌ها می‌توانند به آن‌ها ارسال شوند را محدود می‌کند.
upgrade-insecure-requests: به مرورگر دستور می‌دهد تا به طور خودکار درخواست‌های ناامن (HTTP) را به درخواست‌های امن (HTTPS) ارتقا دهد.
block-all-mixed-content: از بارگذاری هرگونه محتوای ترکیبی (محتوای HTTP بارگذاری شده روی HTTPS) توسط مرورگر جلوگیری می‌کند.
report-uri: یک URL مشخص می‌کند که مرورگر باید گزارش‌های نقض را هنگام نقض یک سیاست CSP به آن ارسال کند.
report-to: نام گروهی را مشخص می‌کند که در هدر `Report-To` تعریف شده و شامل نقاط پایانی برای ارسال گزارش‌های نقض است. جایگزین مدرن‌تر و انعطاف‌پذیرتر برای `report-uri` است.

مقادیر لیست منبع CSP

هر دستورالعمل CSP لیستی از مقادیر منبع را می‌پذیرد که مبدأها یا کلمات کلیدی مجاز را مشخص می‌کنند.

'self': اجازه می‌دهد منابع از همان مبدأ صفحه وب بارگذاری شوند.
'none': بارگذاری منابع از همه مبدأها را غیرمجاز می‌کند.
'unsafe-inline': اجازه استفاده از جاوا اسکریپت و CSS درون‌خطی (inline) را می‌دهد. تا حد امکان باید از این گزینه اجتناب شود، زیرا حفاظت در برابر XSS را تضعیف می‌کند.
'unsafe-eval': اجازه استفاده از eval() و توابع مرتبط را می‌دهد. از این گزینه نیز باید اجتناب شود، زیرا می‌تواند آسیب‌پذیری‌های امنیتی ایجاد کند.
'strict-dynamic': مشخص می‌کند که اعتمادی که به صراحت به یک اسکریپت در مارک‌آپ داده شده (از طریق nonce یا hash همراه آن)، باید به تمام اسکریپت‌هایی که توسط آن اسکریپت ریشه بارگذاری می‌شوند، منتقل شود.
https://example.com: اجازه می‌دهد منابع از یک دامنه خاص بارگذاری شوند.
*.example.com: اجازه می‌دهد منابع از هر زیردامنه‌ای از یک دامنه خاص بارگذاری شوند.
data:: اجازه استفاده از data URIها را می‌دهد (تصاویر کدگذاری شده با base64).
mediastream:: اجازه استفاده از `mediastream:` URIها را برای `media-src` می‌دهد.
blob:: اجازه استفاده از `blob:` URIها را می‌دهد (برای داده‌های باینری ذخیره شده در حافظه مرورگر استفاده می‌شود).
filesystem:: اجازه استفاده از `filesystem:` URIها را می‌دهد (برای دسترسی به فایل‌های ذخیره شده در سیستم فایل سندباکس مرورگر استفاده می‌شود).
nonce-{random-value}: اجازه می‌دهد اسکریپت‌ها یا استایل‌های درون‌خطی که دارای ویژگی nonce منطبق هستند، اجرا شوند.
sha256-{hash-value}: اجازه می‌دهد اسکریپت‌ها یا استایل‌های درون‌خطی که دارای هش sha256 منطبق هستند، اجرا شوند.

پیاده‌سازی CSP

چندین راه برای پیاده‌سازی CSP وجود دارد:

هدر HTTP: رایج‌ترین راه برای پیاده‌سازی CSP، تنظیم هدر HTTP Content-Security-Policy در پاسخ سرور است.
تگ Meta: CSP را می‌توان با استفاده از تگ <meta> در سند HTML نیز تعریف کرد. با این حال، این روش انعطاف‌پذیری کمتری دارد و دارای محدودیت‌هایی است (مثلاً نمی‌توان از آن برای تعریف دستورالعمل frame-ancestors استفاده کرد).

مثال (تنظیم CSP از طریق هدر HTTP - آپاچی):

در فایل پیکربندی آپاچی خود (مثلاً .htaccess یا httpd.conf)، خط زیر را اضافه کنید:


Header set Content-Security-Policy "default-src 'self'; script-src 'self' https://example.com; style-src 'self' https://cdn.example.com; img-src 'self' data:; font-src 'self';"

مثال (تنظیم CSP از طریق هدر HTTP - انجین‌اکس):

در فایل پیکربندی Nginx خود (مثلاً nginx.conf)، خط زیر را به بلوک server اضافه کنید:


add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://example.com; style-src 'self' https://cdn.example.com; img-src 'self' data:; font-src 'self';";

مثال (تنظیم CSP از طریق تگ Meta):


<meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'self' https://example.com; style-src 'self' https://cdn.example.com; img-src 'self' data:; font-src 'self';">

آزمایش CSP

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

گزارش‌دهی CSP

از دستورالعمل‌های `report-uri` یا `report-to` برای پیکربندی گزارش‌دهی CSP استفاده کنید. این به سرور شما اجازه می‌دهد تا هنگام نقض سیاست CSP، گزارش‌هایی دریافت کند. این اطلاعات می‌تواند برای شناسایی و رفع آسیب‌پذیری‌های امنیتی بسیار ارزشمند باشد.

مثال (CSP با report-uri):


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

مثال (CSP با report-to - مدرن‌تر):


Report-To: {"group":"csp-endpoint","max_age":10886400,"endpoints":[{"url":"https://your-domain.com/csp-report-endpoint"}]}
Content-Security-Policy: default-src 'self'; report-to csp-endpoint;

نقطه پایانی سمت سرور (در این مثال‌ها `/csp-report-endpoint`) باید برای دریافت و پردازش این گزارش‌های JSON پیکربندی شود و آن‌ها را برای تحلیل‌های بعدی ثبت کند.

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

با یک سیاست سختگیرانه شروع کنید: با یک سیاست محدودکننده که فقط به منابع از همان مبدأ اجازه می‌دهد (default-src 'self') شروع کنید. به تدریج سیاست را در صورت نیاز شل کنید و منابع خاص مورد نیاز را اضافه کنید.
از 'unsafe-inline' و 'unsafe-eval' اجتناب کنید: این دستورالعمل‌ها به طور قابل توجهی حفاظت در برابر XSS را تضعیف می‌کنند. سعی کنید تا حد امکان از آنها اجتناب کنید. از nonceها یا هش‌ها برای اسکریپت‌ها و استایل‌های درون‌خطی استفاده کنید و از استفاده از eval() خودداری کنید.
از nonceها یا هش‌ها برای اسکریپت‌ها و استایل‌های درون‌خطی استفاده کنید: اگر مجبور به استفاده از اسکریپت‌ها یا استایل‌های درون‌خطی هستید، از nonceها یا هش‌ها برای قرار دادن آنها در لیست سفید استفاده کنید.
از گزارش‌دهی CSP استفاده کنید: گزارش‌دهی CSP را برای دریافت اعلان‌ها هنگام نقض سیاست پیکربندی کنید. این به شما در شناسایی و رفع آسیب‌پذیری‌های امنیتی کمک می‌کند.
پیاده‌سازی CSP خود را به طور کامل آزمایش کنید: از ابزارهای توسعه‌دهنده مرورگر برای بازرسی هدر Content-Security-Policy و بررسی هرگونه نقض استفاده کنید.
از یک تولیدکننده CSP استفاده کنید: چندین ابزار آنلاین می‌توانند به شما در تولید هدرهای CSP بر اساس نیازهای خاص شما کمک کنند.
گزارش‌های CSP را نظارت کنید: به طور منظم گزارش‌های CSP را برای شناسایی مشکلات امنیتی بالقوه و اصلاح سیاست خود بررسی کنید.
CSP خود را به‌روز نگه دارید: با تکامل وب‌سایت خود، حتماً CSP خود را برای انعکاس هرگونه تغییر در وابستگی‌های منابع به‌روز کنید.
استفاده از یک لینتر سیاست امنیت محتوا (CSP) را در نظر بگیرید: ابزارهایی مانند `csp-html-webpack-plugin` یا افزونه‌های مرورگر می‌توانند به اعتبارسنجی و بهینه‌سازی پیکربندی CSP شما کمک کنند.
CSP را به تدریج اعمال کنید (حالت فقط گزارش): در ابتدا CSP را در حالت "فقط گزارش" با استفاده از هدر `Content-Security-Policy-Report-Only` مستقر کنید. این به شما امکان می‌دهد تا نقض‌های بالقوه سیاست را بدون مسدود کردن واقعی منابع، نظارت کنید. گزارش‌ها را برای تنظیم دقیق CSP خود قبل از اعمال آن، تجزیه و تحلیل کنید.

مثال (پیاده‌سازی Nonce):

سمت سرور (تولید Nonce):


<?php
$nonce = base64_encode(random_bytes(16));
?>

HTML:


<script nonce="<?php echo $nonce; ?>">
  // اسکریپت درون‌خطی شما در اینجا
  console.log('Inline script with nonce');
</script>

هدر CSP:


Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-<?php echo $nonce; ?>';

CSP و کتابخانه‌های شخص ثالث

هنگام استفاده از کتابخانه‌های شخص ثالث یا CDNها، حتماً دامنه‌های آنها را در سیاست CSP خود بگنجانید. برای مثال، اگر از jQuery از یک CDN استفاده می‌کنید، باید دامنه CDN را به دستورالعمل script-src اضافه کنید.

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

یکپارچگی منابع فرعی (SRI)

SRI یک ویژگی امنیتی است که به مرورگرها اجازه می‌دهد تا تأیید کنند فایل‌هایی که از CDNها یا دیگر منابع شخص ثالث دریافت می‌شوند، دستکاری نشده‌اند. SRI با مقایسه یک هش رمزنگاری شده از فایل دریافت شده با یک هش شناخته شده کار می‌کند. اگر هش‌ها مطابقت نداشته باشند، مرورگر از بارگیری فایل جلوگیری می‌کند.

مثال:


<script src="https://example.com/jquery.min.js" integrity="sha384-example-hash" crossorigin="anonymous"></script>

ویژگی integrity حاوی هش رمزنگاری شده فایل jquery.min.js است. ویژگی crossorigin برای کارکرد SRI با فایل‌هایی که از مبدأهای مختلف ارائه می‌شوند، الزامی است.

نتیجه‌گیری

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

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