تست امنیت وب چطور در سطح پروتکل و مرورگر انجام می‌شود؟

یکی از عجیب‌ترین پرونده‌هایی که در پروژه‌ها دیدم، سایتی بود که در تست اپلیکیشن تمام نمرات مثبت گرفته بود: بدون تزریق SQL، بدون XSS، بدون IDOR. اما وقتی تست را در سطح لایه وب و مرورگر بردم، یک کوکی نشست بدون Secure و HttpOnly روی مسیر غیر HTTPS، با سقف نگهداری یک ساله، دقیقاً همان چیزی بود که مهاجم برای ربودن حساب مدیر به آن نیاز داشت. آن روز برای من روشن شد که تست امنیت وب (Web Security Testing) در سطح پروتکل، چیزی متفاوت از تست اپلیکیشن است. این مقاله، دقیقاً همان لایه‌ای را باز می‌کند که تیم‌ها غالباً نادیده می‌گیرند: لایه پروتکل HTTP، هدرها، کوکی‌ها، TLS و تعامل با مرورگر.

تست امنیت وب، دقیقاً چه لایه‌ای است؟

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

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

اهمیت این لایه به این دلیل است که بسیاری از آسیب‌پذیری‌های مدرن، از جنس رخنه در همین مرزها هستند. مثلاً حمله‌ای که در آن یک کوکی بدون SameSite، در یک درخواست Cross-Site فرستاده می‌شود، نه مشکل کد اپلیکیشن است و نه مشکل زیرساخت؛ مشکل لایه وب است. مرور کلی این کلاس‌ها در آسیب‌پذیری وب چیست آمده است.

تست امنیت وب، نه از جنس کد است و نه از جنس سرور؛ از جنس قراردادی است که مرورگر و سرور با هم پذیرفته‌اند. آن قرارداد را باید بازرسی کرد، نه کد.

تفاوت با تست امنیت اپلیکیشن

یک پرسش رایج در جلسات: تفاوت تست امنیت وب و تست امنیت اپلیکیشن چیست؟ پاسخ کوتاه این است که در تست اپلیکیشن، هدف پیدا کردن خطا در منطق برنامه است؛ در تست لایه وب، هدف پیدا کردن خطا در نحوه استفاده برنامه از استانداردهای وب است.

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

تست هدرهای امنیتی HTTP

هدرهای امنیتی HTTP، اولین خط دفاعی در سطح مرورگر هستند. هر کدام از این هدرها، یک قاعده به مرورگر می‌گویند که چگونه با محتوای صفحه رفتار کند. تست این هدرها، ساده و در عین حال پرثمر است. فهرست هدرهایی که در هر تست بررسی می‌کنم:

• Strict-Transport-Security (HSTS): مرورگر را ملزم می‌کند که در بازه مشخصی، فقط از طریق HTTPS به دامنه وصل شود. نبود این هدر، امکان SSL Strip را باز می‌کند. نکات فنی این هدر در هدرهای امنیتی HTTP آمده است.
• Content-Security-Policy (CSP): تعیین می‌کند کدام منابع می‌توانند لود شوند. یک CSP ضعیف یا نبود آن، اثر هر XSS را به‌طور چشمگیری بالا می‌برد.
• X-Content-Type-Options: nosniff: جلوگیری از MIME Type Sniffing که در برخی مرورگرهای قدیمی، امکان اجرای فایل‌های غیرقابل‌اجرا را فراهم می‌کرد.
• X-Frame-Options یا frame-ancestors در CSP: جلوگیری از Clickjacking. نبود این هدر، سایت شما را در iframe قابل بارگذاری می‌کند.
• Referrer-Policy: تعیین می‌کند چه مقدار از URL فعلی در Referer به دامنه مقصد فرستاده شود. تنظیم ضعیف آن، می‌تواند اطلاعات حساس را در URL leak کند.
• Permissions-Policy: تعیین می‌کند کدام APIهای مرورگر (مثل دوربین، میکروفون، موقعیت) در دسترس اسکریپت‌های صفحه هستند.
• Cross-Origin-Opener-Policy (COOP) و Cross-Origin-Embedder-Policy (COEP): هدرهای نسبتاً جدیدی که مرزهای Cross-Origin را محکم‌تر می‌کنند و در برابر حملات Side-Channel و Spectre مفیدند.

روش تست: با curl -I روی URL هدف، هدرهای پاسخ را دریافت می‌کنم و سپس یک‌به‌یک ارزش هر هدر را بررسی می‌کنم. ابزارهایی مثل Mozilla Observatory یا SecurityHeaders.com هم این کار را خودکار انجام می‌دهند، اما نتیجه‌شان به‌تنهایی برای تصمیم کافی نیست؛ باید ارزش هر هدر را در بستر محصول سنجید.

curl -sI https://example.com | grep -Ei "strict-transport|content-security|x-frame|x-content|referrer|permissions"

یک نکته مهم: تنظیم هدرها در سطح CDN و در سطح وب‌سرور می‌تواند اثر متفاوتی داشته باشد. در برخی پیکربندی‌ها، هدر تنظیم‌شده در CDN ممکن است در برخی مسیرها override نشود یا در مسیرهای خاص نادیده گرفته شود. باید هر مسیر بحرانی را جداگانه تست کرد.

تست کوکی‌ها و Session Management

کوکی‌ها قلب مدیریت نشست (Session Management) در وب هستند. اگر کوکی نشست اشتباه تنظیم شود، تمام لایه‌های امنیتی اپلیکیشن می‌توانند بی‌اثر شوند. سه پرچم اصلی هر کوکی:

• Secure: کوکی فقط در ارتباط HTTPS فرستاده شود. اگر این پرچم نباشد، کوکی روی HTTP هم ارسال می‌شود و امکان شنود فراهم است.
• HttpOnly: کوکی از دسترس جاوااسکریپت خارج می‌شود، در نتیجه حمله XSS نمی‌تواند آن را بدزدد. نبود این پرچم، مستقیماً اثر XSS را چند برابر می‌کند.
• SameSite: تعیین می‌کند کوکی در درخواست Cross-Site فرستاده شود یا نه. مقادیر Strict، Lax و None هر کدام سناریوی متفاوتی از CSRF را ممکن یا مسدود می‌کنند. مقدار None در مرورگرهای جدید، فقط با Secure مجاز است.

روش تست: در DevTools مرورگر، در تب Application، بخش Cookies، هر کوکی را جداگانه بررسی می‌کنم. علاوه بر این، با curl هم می‌توان کوکی‌ها را در پاسخ بررسی کرد. جزئیات بیشتر درباره CSRF و تعاملش با کوکی در CSRF چیست و چگونه از آن جلوگیری کنیم آمده است.

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

1. کوکی نشست بدون Secure و HttpOnly: شایع‌ترین یافته در پروژه‌های کوچک.
2. کوکی با SameSite=None و بدون Secure: در مرورگرهای جدید رد می‌شود، اما در برخی مرورگرهای قدیمی می‌تواند مورد استفاده قرار گیرد.
3. کوکی با Domain گسترده: اگر کوکی با Domain=.example.com تنظیم شود، همه زیردامنه‌ها به آن دسترسی دارند. اگر یکی از زیردامنه‌ها در اختیار سرویس خارجی باشد، آن سرویس می‌تواند کوکی نشست اصلی را ببیند.
4. کوکی با مسیر (Path) اشتباه: اگر مسیر کوکی خیلی گسترده باشد، در مسیرهایی که نباید فرستاده شود، فرستاده می‌شود.
5. نبود مکانیزم چرخش نشست (Session Rotation) پس از ورود: مهاجمی که قبل از ورود کاربر، یک نشست ساخته، می‌تواند بعد از ورود کاربر همان نشست را بردارد. این حمله با عنوان Session Fixation شناخته می‌شود.

تست CORS و Same-Origin Policy

CORS (Cross-Origin Resource Sharing) یکی از پرتکرارترین محل‌های اشتباه پیکربندی در لایه وب است. مکانیزم Same-Origin Policy مرورگر، به‌طور پیش‌فرض از دسترسی دامنه‌های مختلف به منابع یکدیگر جلوگیری می‌کند. اما اگر سرور به‌درستی پیکربندی نشود، این مکانیزم می‌تواند به‌طور کامل بی‌اثر شود.

سه اشتباه رایج که در تست‌ها کشف کرده‌ام:

• Access-Control-Allow-Origin با مقدار wildcard روی منابع حساس: اگر پاسخ به درخواست‌های کاربران احراز هویت‌شده با Access-Control-Allow-Origin: * برگردد و هم‌زمان اعتبارنامه (Credential) هم پذیرفته شود، مهاجم می‌تواند از دامنه خودش درخواست بفرستد و به داده پاسخ دسترسی پیدا کند. مرورگرهای جدید از ترکیب wildcard با Credential جلوگیری می‌کنند، اما برخی پیاده‌سازی‌های سفارشی این قاعده را نقض می‌کنند.
• بازتاب دادن Origin درخواست: سروری که به‌جای لیست سفید، مقدار Origin دریافتی را در پاسخ بازتاب می‌دهد، عملاً از هر دامنه‌ای درخواست می‌پذیرد.
• پذیرش null به‌عنوان Origin: در برخی سناریوهای sandbox، Origin مرورگر به null تنظیم می‌شود. اگر سرور null را بپذیرد، راه برای فرار از محدودیت‌های CORS باز می‌شود.

تست این لایه با ارسال درخواست‌های Preflight (OPTIONS) و درخواست‌های واقعی از originهای مختلف انجام می‌شود. ابزارهایی مثل Burp Suite و همچنین روش دستی با curl روی endpoints حساس، بهترین نتیجه را می‌دهند. این نوع آسیب‌پذیری مستقیماً از جنس آسیب‌پذیری‌های رایج وب است، اما در بسیاری از فهرست‌های OWASP Top 10 به‌طور صریح دیده نمی‌شود.

تست CSP و سیاست محتوا

CSP (Content Security Policy) یکی از مؤثرترین ابزارهای کاهش اثر XSS است. اما تنها زمانی مؤثر است که به‌درستی پیکربندی شود. سه اشتباه رایج که در تست CSP کشف می‌کنم:

1. استفاده از unsafe-inline: این دستور، عملاً بخش بزرگی از حفاظت CSP در برابر XSS را بی‌اثر می‌کند. اگر صفحه به‌طور ناگزیر نیاز به inline script دارد، باید با nonce یا hash کنترل شود، نه unsafe-inline.
2. لیست منابع بیش از حد گسترده: مثلاً script-src https: که به هر دامنه HTTPS اجازه بارگذاری می‌دهد. این، تقریباً همان بی‌حفاظتی است.
3. وجود هر دو حالت Report-Only و Enforce با پیکربندی متفاوت: گاهی تیم CSP را در حالت Report-Only تنظیم می‌کند و هیچ‌وقت آن را Enforce نمی‌کند. این یعنی CSP فقط لاگ می‌کند، اما جلوی چیزی را نمی‌گیرد.

روش تست: بررسی هدر CSP پاسخ، تجزیه دستورات، شبیه‌سازی سناریوهای XSS و بررسی رفتار مرورگر. ابزارهای CSP Evaluator گوگل و همچنین پلاگین‌های مرورگر، این تحلیل را ساده می‌کنند. اما در نهایت، تصمیم درباره کیفیت CSP نیازمند درک بستر اپلیکیشن است.

CSP یک سیاست اعلامی است، نه یک کنترل اجرایی. اگر درست نوشته نشود، فقط روی کاغذ امن است.

تست SRI و منابع خارجی

SRI (Subresource Integrity) مکانیزمی است که مرورگر را قادر می‌کند صحت یک فایل خارجی (CSS، JS، فونت) را با بررسی hash محتوای آن تأیید کند. اگر SRI تنظیم نشده باشد، حمله Supply Chain Chain می‌تواند از طریق CDN آلوده یا حساب به‌خطرافتاده، کد مخرب را به سایت شما تزریق کند.

روش تست ساده است: تمام تگ‌های <script> و <link> که به دامنه خارجی اشاره می‌کنند، باید ویژگی integrity و crossorigin داشته باشند. اگر دامنه خارجی تحت کنترل شما نیست، SRI یک لایه ضروری است. نمونه:

<script src="https://cdn.example.com/lib.js"
        integrity="sha384-..."
        crossorigin="anonymous"></script>

در تجربه من، بسیاری از سایت‌های ایرانی که از CDNهای عمومی برای لود jQuery یا Bootstrap استفاده می‌کنند، SRI را تنظیم نکرده‌اند. این یک ریسک واقعی است، چون اگر CDN آن دامنه در آینده با حمله‌ای مواجه شود، همه سایت‌هایی که به آن اعتماد کرده‌اند، آسیب می‌بینند.

تست Clickjacking و X-Frame-Options

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

روش تست ساده است: یک فایل HTML ساده بسازید که صفحه سایت هدف را در iframe بارگذاری کند. اگر صفحه بارگذاری شد، سایت در برابر Clickjacking آسیب‌پذیر است. اگر مرورگر بارگذاری را رد کرد، هدر درست تنظیم شده است. نمونه تست:

<iframe src="https://target.example.com" width="800" height="600"></iframe>

در پیکربندی درست، باید یا X-Frame-Options: DENY تنظیم شود یا در CSP دستور frame-ancestors 'none' اضافه شود. دومی توصیه‌شده است، چون CSP در سطح دقیق‌تری می‌تواند دامنه‌های مجاز را مشخص کند.

تست TLS و HTTPS

لایه TLS (Transport Layer Security) بستر رمزنگاری همه ارتباطات وب است. تست این لایه، اگرچه تخصصی است، اما با ابزارهای مناسب ساده می‌شود. چیزی که در تست TLS بررسی می‌کنم:

• پروتکل‌های پشتیبانی‌شده: TLS 1.0 و TLS 1.1 باید غیرفعال باشند. فقط TLS 1.2 و TLS 1.3 قابل قبول هستند. تنظیمات قدیمی در SSL چیست و چرا سایت به آن نیاز دارد آمده است.
• الگوریتم‌های رمزنگاری (Cipher Suites): الگوریتم‌های ضعیف مثل RC4، 3DES و CBC قدیمی باید غیرفعال شوند. فقط الگوریتم‌های AEAD مثل AES-GCM و ChaCha20 قابل قبولند.
• پشتیبانی از Forward Secrecy: اگر کلید سرور در آینده به‌دست مهاجم بیفتد، ترافیک گذشته قابل رمزگشایی نباشد. الگوریتم‌های ECDHE این ویژگی را فراهم می‌کنند.
• زنجیره گواهی (Certificate Chain): بررسی این‌که گواهی از یک CA (Certificate Authority) معتبر صادر شده و زنجیره کامل است.
• تاریخ انقضا و پیکربندی OCSP Stapling: گواهی نزدیک به انقضا، باید به‌موقع تمدید شود. OCSP Stapling سرعت بررسی اعتبار گواهی را افزایش می‌دهد.
• HSTS و Preload: بررسی این‌که هدر HSTS فعال است و دامنه در لیست Preload مرورگرها قرار دارد یا نه.

ابزار تخصصی این لایه، SSLyze و testssl.sh هستند که هر دو رایگان و قدرتمندند. Qualys SSL Labs هم ارزیابی جامعی از پیکربندی ارائه می‌دهد. در تجربه من، تست دوره‌ای این لایه لازم است، چون با هر به‌روزرسانی سرور یا CDN، ممکن است پیکربندی به‌طور پیش‌فرض به عقب برگردد.

تست سمت مرورگر و DOM

لایه سمت مرورگر، محل تلاقی پروتکل و منطق اپلیکیشن است. تست‌های این لایه شامل موارد زیر است:

• بررسی Content-Type و Charset: تنظیم نادرست MIME Type، می‌تواند حمله را ممکن کند. مثلاً سروری که فایل JSON را با Content-Type: text/html برمی‌گرداند، می‌تواند به XSS منجر شود.
• تست DOM-based XSS: در این نوع حمله، داده مخرب از طریق URL Fragment، postMessage یا سینک‌های دیگر مرورگر به DOM تزریق می‌شود، بدون این‌که به سرور برسد. این کلاس، اسکنرهای خودکار را دور می‌زند و نیازمند تحلیل دستی کد کلاینت است. مرور کلی در حملات XSS چیست و چگونه دفع می‌شود آمده است.
• تست PostMessage و Cross-Window Communication: اگر برنامه از postMessage استفاده می‌کند و origin را بررسی نمی‌کند، مهاجم می‌تواند پیام‌های مخرب بفرستد.
• تست LocalStorage و IndexedDB: بررسی این‌که داده‌های حساس (توکن‌ها، اطلاعات کاربر) در این مخازن ذخیره نشده باشند. ذخیره توکن نشست در LocalStorage، با یک XSS معادل ربودن حساب است.
• تست Service Worker و Cache Storage: در برنامه‌های PWA، بررسی این‌که Service Worker از منابع معتبر بارگذاری شده و در دامنه‌های Cross-Origin اثر نمی‌گذارد.

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

جعبه‌ابزار لایه وب

ابزارهای لایه وب معمولاً سبک‌تر و متن‌بازتر از ابزارهای اپلیکیشن هستند. فهرستی از ابزارهایی که در پروژه‌ها به‌طور مرتب استفاده می‌کنم:

در تجربه من، شروع کار با curl و DevTools در ۸۰٪ موارد کافی است. ابزارهای اختصاصی برای تست‌های عمیق‌تر مثل TLS و تحلیل CSP کاربرد دارند. برای مشاهده ابزارهای جامع‌تر، فهرست اسکنرهای آسیب‌پذیری وب را ببینید.

تست لایه وب در سایت‌های وردپرسی

در بستر وردپرس، سه لایه لایه وب اختصاصی وجود دارد که باید در تست جداگانه بررسی شوند:

1. هدرهای امنیتی در وردپرس: به‌طور پیش‌فرض، وردپرس برخی هدرها را تنظیم می‌کند، اما HSTS، CSP و Permissions-Policy معمولاً تنظیم نمی‌شوند. باید در فایل .htaccess، پیکربندی وب‌سرور یا پلاگین تخصصی تنظیم شوند. راهنمای امن‌سازی wp-config نقطه شروع خوبی است.
2. کوکی‌های وردپرس: کوکی‌های پیش‌فرض وردپرس (wordpress_logged_in_*) در نسخه‌های جدید پرچم Secure و HttpOnly و SameSite را به‌درستی تنظیم می‌کنند، اما افزونه‌های شخص ثالث معمولاً این قاعده را رعایت نمی‌کنند. تست کوکی‌های افزونه‌ها در سایت‌های وردپرسی، یکی از پرثمرترین بخش‌های تست است.
3. CSP در وردپرس: افزودن CSP در وردپرس چالش‌برانگیز است، چون تعداد زیادی از افزونه‌ها از inline script استفاده می‌کنند. تنظیم CSP بدون شکستن سایت، نیازمند استفاده از nonce و به‌روزرسانی تدریجی است. در پروژه‌های بزرگ، CSP را ابتدا در حالت Report-Only فعال می‌کنم، لاگ‌ها را چند هفته جمع می‌کنم، سپس Enforce می‌کنم.

یک نکته مهم درباره تست لایه وب در وردپرس: بسیاری از یافته‌ها در این لایه، از افزونه‌ها یا قالب‌های شخص ثالث می‌آید، نه از هسته. بنابراین، فهرست کردن افزونه‌ها و بررسی امنیتی هر کدام، بخش ضروری تست است. راهنمای آسیب‌پذیری افزونه‌های وردپرس در این زمینه مفید است.

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

پرسش‌هایی که در پروژه‌ها زیاد می‌شنوم، با پاسخ کوتاه و عملی:

آیا تست لایه وب جایگزین تست اپلیکیشن است؟

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

هدرهای امنیتی HTTP را از کجا تنظیم کنم؟

بستگی به معماری دارد. اگر سایت با CDN سرو می‌شود، معمولاً در لایه CDN تنظیم می‌شود. اگر سرور مستقل است، در پیکربندی Apache، Nginx یا LiteSpeed. برای وردپرس، می‌توان با .htaccess هم تنظیم کرد. توصیه من: در همه لایه‌ها، یک هدر مشترک تنظیم کنید تا در صورت override شدن یکی، دیگری بماند.

چطور CSP را بدون شکستن سایت تست کنم؟

سه‌مرحله‌ای: ابتدا در حالت Report-Only با یک endpoint گزارش‌گیری راه‌اندازی کنید. چند هفته لاگ جمع کنید. سپس دستورات را محدودتر کنید و به Enforce تغییر دهید. همیشه یک مسیر اضطراری برای Disable CSP داشته باشید.

آیا HSTS روی همه دامنه‌ها و زیردامنه‌ها لازم است؟

در پروژه‌های معمول، تنظیم HSTS روی دامنه اصلی و زیردامنه‌های HTTPS کافی است. اما دقت کنید: فعال‌کردن HSTS با Preload روی زیردامنه‌هایی که هنوز HTTPS ندارند، می‌تواند دسترسی را از دست بدهد. تست اولیه روی محیط آزمایشی الزامی است.

چطور بفهمم گواهی TLS درست پیکربندی شده؟

با testssl.sh یا sslyze. این ابزارها فهرست کامل الگوریتم‌ها، پروتکل‌ها و گواهی‌ها را با درجه اعتبار نمایش می‌دهند. Qualys SSL Labs هم گرید نهایی می‌دهد. اگر گرید A نگرفتید، یعنی جایی برای بهبود هست.

آیا SameSite=Lax روی همه کوکی‌ها کافی است؟

برای اکثر موارد، بله. اما در سناریوهای Cross-Site نیازمند (مثل SSO یا برخی APIها)، مقدار None با Secure لازم است. همیشه برای هر کوکی، سناریوی استفاده واقعی را بررسی کنید؛ یک نسخه یکسان برای همه، معمولاً اشتباه است.

تست لایه وب را هر چند وقت یک‌بار انجام دهم؟

پس از هر تغییر در لایه CDN، وب‌سرور یا پیکربندی TLS، حتماً تست کوتاه. برای تغییرات اپلیکیشن، فصل‌ای یک بار تست کامل لایه وب. اگر با CDN کار می‌کنید که پیکربندی‌اش قابل تغییر است، حتی ماهی یک بار تست سریع هدرها و CSP منطقی است.

درس‌هایی از پروتکل که فراموش می‌شوند

تست امنیت وب در سطح پروتکل، لایه‌ای است که غالباً بین دو دنیای اپلیکیشن و زیرساخت، گم می‌شود. اما همین لایه است که در بسیاری از حوادث واقعی، به مهاجم امکان می‌دهد که یک آسیب‌پذیری کوچک را به یک رخنه کامل تبدیل کند. سه اولویت اگر بخواهم در این لایه پیشنهاد کنم: اول، بررسی دقیق کوکی‌ها و پرچم‌هایشان؛ دوم، پیکربندی صحیح هدرهای امنیتی و CSP؛ سوم، تست دوره‌ای لایه TLS.

اگر در پروژه‌ای این لایه را تست کرده‌اید، برایم جالب است بدانید کدام یافته بیشترین تأثیر را داشت — یک هدر ساده، یک کوکی اشتباه، یا یک نادرستی در CORS. تجربه‌تان را در دیدگاه‌ها بنویسید؛ به‌خصوص اگر یافته‌ای داشتید که در این مقاله به آن اشاره نشده و در شرایط واقعی مؤثر بوده. 🔐