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

بررسی‌های امنیتی منفعل برای فروشگاه‌های اینترنتی: انقضای گواهی TLS، HSTS، CSP، nosniff، ویژگی‌های کوکی، محتوای ترکیبی، jQuery قدیمی، security.txt و DMARC.

تیم تحریریه FixReports12 دقیقه مطالعه

بخش زیادی از تنظیمات امنیتی یک فروشگاه اینترنتی را می‌توانید از بیرون و با خواندن چیزهایی بررسی کنید که سایت از قبل برای هر بازدیدکننده می‌فرستد: گواهی TLS، ریدایرکت‌ها، هدرهای پاسخ HTTP، کوکی‌ها، اسکریپت‌هایی که بارگذاری می‌کند و رکوردهای DNS عمومی آن. این بررسی‌های منفعل (passive) هیچ ترافیک حمله‌ای نمی‌فرستند و به ورود به حساب نیازی ندارند، بنابراین باری بیش از یک بازدید معمولی بر فروشگاه وارد نمی‌کنند. این بررسی‌ها نقص‌های پیکربندی مانند گواهی رو به انقضا، نبود HSTS، کوکی‌های ناامن، محتوای ترکیبی (mixed content) یا نسخه‌ای از jQuery با آسیب‌پذیری‌های شناخته‌شده را پیدا می‌کنند. آن‌ها تست نفوذ نیستند و نمی‌توانند ثابت کنند که یک فروشگاه امن است.

نکات کلیدی

چه چیزی بررسی امنیتی منفعل به حساب می‌آید؟

بررسی منفعل فقط چیزی را می‌خواند که سایت یا DNS آن در پاسخ به یک درخواست معمولی برمی‌گرداند.

یعنی بارگذاری صفحات عمومی، خواندن گواهی و هدرهای پاسخ، فهرست کردن کوکی‌ها و اسکریپت‌هایی که یک صفحه تنظیم می‌کند و پرس‌وجوی رکوردهای DNS عمومی. بررسی منفعل رمز عبور حدس نمی‌زند، payload تزریق (injection) نمی‌فرستد، URLهای پنل مدیریت را کاوش نمی‌کند و پورت‌ها را اسکن نمی‌کند. همه کارهای زیر را می‌توان با یک مرورگر، curl، openssl و dig انجام داد.

چگونه گواهی TLS و تاریخ انقضای آن را بررسی کنید؟

تاریخ‌ها و نام‌های گواهی را مستقیماً بخوانید و مطمئن شوید تمدید آن خودکار است.

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

بررسی کنید که notAfter با فاصله کافی در آینده باشد، اگر از هر دو example.com و www.example.com استفاده می‌کنید گواهی هر دو را پوشش دهد (نمایشگر گواهی مرورگر نام‌ها را فهرست می‌کند) و مرورگر هیچ هشداری نشان ندهد. طول عمر گواهی‌ها طبق Baseline Requirements انجمن CA/Browser Forum (بخش 6.3.2، نسخه 2.3.1 تا اکتبر 2026) و در پی Ballot SC-081v3 (در زبانه جدید باز می‌شود) که در 11 آوریل 2025 تصویب شد، در حال کوتاه‌تر شدن است:

تاریخ صدور گواهیحداکثر اعتبار
پیش از 15 مارس 2026398 روز
15 مارس 2026 تا 14 مارس 2027200 روز
15 مارس 2027 تا 14 مارس 2029100 روز
از 15 مارس 202947 روز

طول عمر کوتاه، تمدید دستی را پرخطر می‌کند، بنابراین مطمئن شوید میزبان یا ابزار گواهی شما تمدید را به‌طور خودکار انجام می‌دهد. همچنین بررسی کنید که HTTP ساده به HTTPS ریدایرکت شود:

curl -sI http://example.com/ | grep -i -E "^HTTP|^location"

باید پاسخ 301 (یا 308) با هدر location دریافت کنید که با https:// شروع شود.

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

مجموعه کوچکی از هدرهای پاسخ، حملات رایج سمت مرورگر را تقریباً بدون هزینه مسدود می‌کند.

هدرچه کاری انجام می‌دهدمقدار معمولمنبع
Strict-Transport-Securityبه مرورگرها می‌گوید فقط از HTTPS استفاده کنند و نمی‌گذارد کاربران با نادیده گرفتن خطاهای گواهی وارد سایت شوندmax-age=31536000; includeSubDomainsMDN (در زبانه جدید باز می‌شود)
Content-Security-Policy: frame-ancestorsتعیین می‌کند کدام سایت‌ها می‌توانند صفحات شما را جاسازی (embed) کنند و در برابر کلیک‌جکینگ (clickjacking) محافظت می‌کندframe-ancestors 'self'MDN (در زبانه جدید باز می‌شود)
X-Frame-Optionsروش قدیمی‌تر کنترل قاب‌بندی (framing)؛ به گفته OWASP، در مرورگرهای پشتیبانی‌کننده frame-ancestors آن را منسوخ کرده استDENY یا SAMEORIGINOWASP (در زبانه جدید باز می‌شود)
X-Content-Type-Optionsجلوی MIME sniffing را می‌گیرد و اسکریپت‌ها و استایل‌شیت‌هایی را که با نوع نادرست ارسال شده‌اند مسدود می‌کندnosniffMDN (در زبانه جدید باز می‌شود)
Referrer-Policyمحدود می‌کند چه مقدار از URLهای شما برای سایت‌های دیگر ارسال شودstrict-origin-when-cross-originOWASP
X-XSS-Protectionهدر فیلتر XSS مرورگر؛ به گفته OWASP می‌تواند در سایت‌هایی که در غیر این صورت امن هستند آسیب‌پذیری XSS ایجاد کندتنظیم نکنید، یا 0OWASP

بررسی کنید فروشگاه شما چه چیزی می‌فرستد:

curl -sI https://example.com/

Strict-Transport-Security: max-age=31536000; includeSubDomains
Content-Security-Policy: frame-ancestors 'self'
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin

دو هشدار. includeSubDomains هر زیردامنه‌ای را که فقط روی HTTP کار می‌کند مسدود می‌کند، پس ابتدا زیردامنه‌ها را بررسی کنید. پیش‌بارگذاری HSTS (preload) به max-age دست‌کم 31536000 و includeSubDomains نیاز دارد، پس فقط وقتی preload را اضافه کنید که همه زیردامنه‌ها برای HTTPS آماده باشند. یک CSP کامل که اسکریپت‌ها را محدود کند ارزش داشتن دارد، اما OWASP یادآوری می‌کند که پیکربندی و نگهداری آن پیچیده است و فروشگاه‌هایی که اپ‌های زیادی دارند باید آن را با دقت آزمایش کنند.

آیا کوکی‌های شما با Secure، HttpOnly و SameSite تنظیم شده‌اند؟

کوکی‌های نشست (session) و سبد خرید باید هر سه ویژگی را داشته باشند و می‌توانید آن‌ها را در هدرهای پاسخ Set-Cookie ببینید.

ویژگیاثر (طبق MDN (در زبانه جدید باز می‌شود))کجا اهمیت دارد
Secureفقط روی HTTPS ارسال می‌شود؛ سایت‌هایی که روی HTTP ساده هستند نمی‌توانند آن را تنظیم کنندهمه کوکی‌ها در فروشگاهی که روی HTTPS است
HttpOnlyJavaScript نمی‌تواند آن را از طریق document.cookie بخواند و این در برابر XSS کمک می‌کندنشست‌های ورود و سبدهای خرید
SameSite=Lax یا Strictمحدود می‌کند کوکی در چه مواقعی در درخواست‌های بین‌سایتی (cross-site) ارسال شودنشست‌ها؛ Strict برای کوکی‌های احراز هویت و سبد خرید مناسب است
SameSite=Noneدر درخواست‌های بین‌سایتی ارسال می‌شود؛ باید همراه با Secure به کار رودفقط قابلیت‌های جاسازی‌شده شخص ثالث که به آن نیاز دارند

اگر هیچ ویژگی SameSite تنظیم نشده باشد، مرورگرها کوکی را Lax در نظر می‌گیرند. کوکی‌هایی که اسکریپت‌های خودتان باید بخوانند نمی‌توانند HttpOnly باشند، پس روی کوکی‌هایی تمرکز کنید که یک مشتری واردشده به حساب یا یک مدیر را شناسایی می‌کنند.

curl -sI https://example.com/ | grep -i "^set-cookie"

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

چگونه محتوای ترکیبی (mixed content) را پیدا کنید؟

محتوای ترکیبی هر منبعی است که در صفحه‌ای که روی HTTPS ارائه می‌شود، از طریق HTTP بارگذاری شود و کنسول مرورگر آن را فهرست می‌کند.

MDN (در زبانه جدید باز می‌شود) آن را به دو گروه تقسیم می‌کند. تصاویر، صدا و ویدیو «قابل ارتقا» (upgradable) هستند: مرورگرها به‌طور خودکار آن‌ها را از طریق HTTPS درخواست می‌کنند. اسکریپت‌ها، استایل‌شیت‌ها، iframeها، فونت‌ها و درخواست‌های fetch() «قابل مسدودسازی» (blockable) هستند: مرورگرها آن‌ها را مسدود می‌کنند و هر چیزی که به آن‌ها وابسته بود از کار می‌افتد. درخواست‌های ارتقایافته به یک نشانی IP خالی (بدون نام دامنه) نیز مسدود می‌شوند.

برای پیدا کردن آن، کنسول را در تمپلیت‌های کلیدی خود (صفحه اصلی، کالکشن، محصول، سبد خرید) باز کنید و کد قالب، محتوای صفحات و تنظیمات اپ‌ها را برای http:// جستجو کنید. مرکز راهنمای Shopify می‌گوید هر صفحه فروشگاه که منبعی (asset) دارد که از طریق HTTPS ارائه نمی‌شود، ناامن تلقی می‌شود (در زبانه جدید باز می‌شود) و توصیه می‌کند منابع را روی Shopify میزبانی کنید یا از طریق HTTPS ارائه دهید. در WooCommerce، اگر سایت زمانی روی http:// اجرا می‌شده، محتوای پست‌های قدیمی و تنظیمات قالب را بررسی کنید.

چگونه کتابخانه‌های JavaScript قدیمی با CVEهای شناخته‌شده را تشخیص دهید؟

کتابخانه‌هایی را که هر صفحه بارگذاری می‌کند فهرست کنید، نسخه‌هایشان را بخوانید و آن‌ها را با National Vulnerability Database (پایگاه ملی آسیب‌پذیری‌ها) مقایسه کنید.

از jQuery شروع کنید. در کنسول مرورگر، $.fn.jquery نسخه بارگذاری‌شده را برمی‌گرداند (jQuery API (در زبانه جدید باز می‌شود)). نسخه‌هایی که باید علامت بزنید:

CVEنسخه‌های آسیب‌پذیرمشکلامتیاز NVD (v3.1)
CVE-2020-11022 (در زبانه جدید باز می‌شود)1.12.0 تا پیش از 3.5.0ارسال HTML غیرقابل‌اعتماد به متدهایی مانند .html() یا .append() ممکن است باعث اجرای کد شود6.1 متوسط (Medium)
CVE-2020-11023 (در زبانه جدید باز می‌شود)1.0.3 تا پیش از 3.5.0همان مشکل، برای HTML شامل عناصر <option>؛ از 23 ژانویه 2025 در فهرست KEV سازمان CISA6.1 متوسط (Medium)
CVE-2019-11358 (در زبانه جدید باز می‌شود)پیش از 3.4.0آلودگی پروتوتایپ (prototype pollution) از طریق jQuery.extend(true, ...)6.1 متوسط (Medium)

هر دو مشکل سال 2020 در jQuery 3.5.0 رفع شده‌اند. وجود نسخه آسیب‌پذیر یعنی کد معیوب در سایت هست؛ اینکه قابل بهره‌برداری باشد یا نه، به نحوه ارسال داده از سوی سایت به آن بستگی دارد. WordPress از نسخه 5.6 (در زبانه جدید باز می‌شود) نسخه 3.5.1 jQuery را همراه خود دارد، بنابراین jQuery قدیمی در یک فروشگاه WooCommerce نشان‌دهنده WordPress قدیمی یا قالب یا افزونه‌ای است که نسخه خودش را بارگذاری می‌کند. در Shopify، فایل‌های قالب و اپ‌هایی را که اسکریپت تزریق می‌کنند بررسی کنید.

security.txt چیست و آیا فروشگاه شما به آن نیاز دارد؟

یک فایل متنی ساده است که به پژوهشگران امنیتی می‌گوید چگونه یک آسیب‌پذیری را به شما گزارش دهند.

طبق RFC 9116 (در زبانه جدید باز می‌شود) (آوریل 2022، یک RFC از نوع Informational، بنابراین پیروی از آن داوطلبانه است)، این فایل باید از طریق HTTPS در مسیر /.well-known/security.txt و با نوع text/plain ارائه شود. فیلدهای Contact و Expires الزامی هستند و RFC توصیه می‌کند تاریخ Expires کمتر از یک سال بعد باشد.

Contact: mailto:security@example.com
Expires: 2027-09-30T23:00:00.000Z
Preferred-Languages: en
Policy: https://example.com/security-policy

در WooCommerce می‌توانید فایل را روی سرور خود قرار دهید. در یک پلتفرم میزبانی‌شده، بررسی کنید آیا می‌توانید فایلی در آن مسیر منتشر کنید؛ اگر نه، یک راه تماس امنیتی با عنوان واضح در صفحه تماس شما همچنان مفید است.

DMARC چگونه از فروشگاه شما در برابر جعل ایمیل محافظت می‌کند؟

DMARC به شما امکان می‌دهد از ارائه‌دهندگان صندوق پستی بخواهید ایمیل‌هایی را که دامنه شما را در نشانی From به کار می‌برند اما از SPF یا DKIM هم‌تراز عبور نمی‌کنند، قرنطینه یا رد کنند.

رکوردی با p=none فقط گزارش جمع می‌کند؛ جلوی ایمیل جعلی را نمی‌گیرد. مشتریان انتظار دارند تأییدیه‌های سفارش و ایمیل‌های بازنشانی رمز عبور از دامنه شما بیاید، بنابراین ارزش دارد پیام فیشینگی را که دقیقاً دامنه شما را نشان می‌دهد مسدود کنید. سیاست خود را با dig +short TXT _dmarc.example.com بررسی کنید و برای مشخصات فنی به RFC 9989 (در زبانه جدید باز می‌شود) مراجعه کنید. DMARC دامنه‌های مشابه (lookalike) را پوشش نمی‌دهد و فقط از دامنه‌ای محافظت می‌کند که رکورد را منتشر کرده است.

Shopify چه چیزهایی را مدیریت می‌کند و در WooCommerce چه چیزهایی در اختیار شماست؟

Shopify سرورهای پشت ویترین‌های فروشگاهی خود را اداره می‌کند، در حالی که در یک فروشگاه WooCommerce خودمیزبان (self-hosted)، تنظیمات سرور بر عهده شما و میزبانتان است.

بررسیShopifyWooCommerce (خودمیزبان)
گواهی TLSرایگان برای همه دامنه‌هایی که به Shopify اضافه شده‌اند (در زبانه جدید باز می‌شود)؛ برای دامنه‌های شخص ثالث ممکن است تا 48 ساعت طول بکشدمیزبان شما یا راه‌اندازی خودتان
ریدایرکت HTTP به HTTPSپلتفرمتنظیمات وب‌سرور، CDN یا میزبان
هدرهای امنیتیاز سرورهای Shopify ارسال می‌شوندوب‌سرور، CDN یا یک افزونه
ویژگی‌های کوکیکوکی‌های خود Shopify را پلتفرم تنظیم می‌کند؛ کوکی‌های اپ‌ها و قالب بر عهده شماستهسته WordPress، افزونه‌ها و سرور
محتوای ترکیبی و کتابخانه‌های JSقالب، محتوا و اپ‌های شماقالب، محتوا و افزونه‌های شما
security.txt و DMARCدامنه و DNS شمادامنه و DNS شما

وقتی در اکتبر 2026 چند ویترین فروشگاهی میزبانی‌شده روی Shopify را بررسی کردیم، پاسخ‌های آن‌ها شامل HSTS با max-age حدود 91 روز، X-Content-Type-Options: nosniff و یک CSP با upgrade-insecure-requests بود، در حالی که frame-ancestors از فروشگاهی به فروشگاه دیگر فرق می‌کرد. Shopify می‌گوید دارای گواهی انطباق PCI DSS سطح 1 (در زبانه جدید باز می‌شود) است. قالب و اپ‌های نصب‌شده همچنان مسئولیت شما هستند.

در WooCommerce، راهنمای مقاوم‌سازی (hardening) (در زبانه جدید باز می‌شود) WordPress می‌گوید WordPress و افزونه‌ها را به‌روز نگه دارید، افزونه‌هایی را که استفاده نمی‌کنید حذف کنید و از میزبان خود بپرسید چه تدابیر امنیتی‌ای به کار می‌گیرد.

چرا این یک تست نفوذ نیست؟

تست نفوذ به‌طور فعال حملات را امتحان می‌کند؛ بررسی‌های منفعل فقط مشاهده می‌کنند.

استاندارد NIST SP 800-115 تست نفوذ را آزمون امنیتی‌ای تعریف می‌کند که در آن ارزیابان حملات دنیای واقعی را شبیه‌سازی می‌کنند تا راه‌هایی برای دور زدن ویژگی‌های امنیتی یک سیستم پیدا کنند (واژه‌نامه NIST (در زبانه جدید باز می‌شود)). بررسی‌های منفعل نمی‌توانند نقص‌های سمت سرور در افزونه‌ها، رمزهای عبور ضعیف یا تکراری مدیران، نبود احراز هویت دومرحله‌ای، کنترل دسترسی معیوب یا کد آسیب‌پذیری را که هرگز در سورس صفحه ظاهر نمی‌شود ببینند. از آن‌ها به‌عنوان یک خط پایه استفاده کنید که هر زمان بخواهید قابل تکرار است. برای اطمینان عمیق‌تر، یک تست نفوذ با محدوده (scope) مکتوب سفارش دهید، آن هم روی سیستم‌هایی که مالک آن‌ها هستید یا مجوز آزمایششان را دارید.

یک اسکن رایگان نخستین بررسی را روی فروشگاه شما انجام می‌دهد. گزارش امنیت وب‌سایت بررسی‌های منفعل این مقاله را پوشش می‌دهد، از TLS و ریدایرکت‌ها تا هدرها، کوکی‌ها، محتوای ترکیبی، کتابخانه‌های قدیمی، security.txt و DMARC، همراه با راه‌حل برای هر یافته. مانند هر بررسی منفعل دیگری، این گزارش نمی‌تواند امن بودن فروشگاه را تضمین کند.

پرسش‌های متداول

آیا بررسی‌های امنیتی منفعل فروشگاه من را در معرض خطر قرار می‌دهند؟

نه بیشتر از یک بازدید معمولی. این بررسی‌ها همان صفحات عمومی و رکوردهای DNS را درخواست می‌کنند که هر مرورگر یا سرور ایمیلی درخواست می‌کند و تلاشی برای ورود به حساب یا ارسال payload حمله نمی‌کنند.

آیا می‌توانم در Shopify هدرهای امنیتی اضافه کنم؟

هدرهای پاسخ ویترین فروشگاه از سرورهای Shopify می‌آیند، بنابراین اگر هدری که نیاز دارید وجود ندارد، با پشتیبانی Shopify تماس بگیرید. یک تگ <meta> مربوط به CSP در قالب شما می‌تواند برخی دستورها را اضافه کند، اما MDN یادآوری می‌کند که frame-ancestors در <meta> پشتیبانی نمی‌شود.

آیا نسخه قدیمی jQuery یعنی فروشگاه من هک شده است؟

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

گواهی TLS اکنون حداکثر چه مدت می‌تواند معتبر باشد؟

گواهی‌های مورد اعتماد عمومی که از 15 مارس 2026 صادر می‌شوند حداکثر 200 روز اعتبار دارند. این حد از 15 مارس 2027 به 100 روز و از 15 مارس 2029 به 47 روز کاهش می‌یابد.

آیا داشتن فایل security.txt الزامی است؟

RFC 9116 یک RFC از نوع Informational است، بنابراین انتشار این فایل طبق این استاندارد داوطلبانه است. انتشار آن هزینه کمی دارد و راه روشنی برای تماس پژوهشگران با شما فراهم می‌کند.

آیا نتیجه بدون مشکل یک اسکن منفعل یعنی فروشگاه من امن است؟

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

منابع

همه راهنماها