امنیت فروشگاه اینترنتی: سایت، درگاه و فرایند عملیاتی

«فروشگاه ما امن است چون SSL دارد.» این جمله در بهترین حالت یک‌دهم ماجراست. امنیت فروشگاه اینترنتی ترکیبی از کار سایت، درگاه پرداخت و فرایندهای عملیاتی است، و بیشتر حادثه‌ها در شکاف بین این سه رخ می‌دهد: سفارشی که با یک درخواست جعلی «پرداخت‌شده» شد، پنل مدیریتی که دسترسی‌اش گشاد بود، وابستگی قدیمی که به‌روز نشد، یا لاگی که هیچ‌کس نخواند. این مقاله مسئولیت‌ها را تفکیک می‌کند و چک‌لیست عملیاتی می‌دهد.

مرز صریح: این مقاله هیچ ادعای انطباق (PCI DSS، الزامات بانک مرکزی، قوانین حریم خصوصی یا الزامات شاپرک) نمی‌کند و نمی‌گوید فروشگاه شما «مطابق» است. این‌ها به منبع رسمی روز و ارزیاب مجاز نیاز دارند. ما آنچه از OWASP، مستند Stripe و مستند زرین‌پال خوانده‌ایم نقل می‌کنیم و بقیه را «توصیهٔ نویسنده» می‌نامیم. فهرست OWASP را از نسخهٔ ۲۰۲۵ آورده‌ایم؛ اگر نسخهٔ جدیدتر منتشر شده باشد باید دوباره بررسی شود.

چه کسی مسئول چیست؟

پیش از هر چک‌لیست، سه ناحیه را از هم جدا کنید:

این تفکیک را مستند Stripe هم تأیید می‌کند: انطباق PCI «مسئولیت مشترک» است. این‌که در قرارداد شما با درگاه ایرانی دقیقاً چه کسی مسئول چیست، باید از خود قرارداد و منبع رسمی روشن شود؛ این مقاله آن را بررسی نکرده است.

داده کارت: بهترین راه این است که از سرور شما رد نشود

Stripe می‌گوید PCI DSS برای هر نهادی است که داده کارت را ذخیره، پردازش یا منتقل می‌کند، و اگر کسب‌وکاری مستقیم داده کارت را دریافت کند ممکن است مشمول بیش از ۳۰۰ کنترل شود. توصیهٔ Stripe استفاده از «یکپارچه‌سازی کم‌ریسک» است که اطلاعات را بدون عبور از سرورهای شما جمع می‌کند و تعهدات را کم می‌کند. جریان مستند زرین‌پال هم همین الگو را دارد: خریدار با ریدایرکت به صفحهٔ درگاه می‌رود و اطلاعات کارت را آن‌جا وارد می‌کند، نه در فروشگاه. قاعدهٔ ساده برای شما (توصیهٔ نویسنده): فیلد شمارهٔ کارت، CVV2 و رمز دوم را هرگز در فرم‌ها، لاگ‌ها، آنالیتیکس و پیام‌های خطای فروشگاه نگیرید و ذخیره نکنید. زرین‌پال در پاسخ verify فقط شمارهٔ کارت ماسک‌شده و هش کارت می‌دهد؛ همان را ذخیره کنید، نه چیزی بیشتر.

نقشهٔ ریسک: OWASP Top 10:2025 برای فروشگاه

فهرست ۲۰۲۵ شامل A01 کنترل دسترسی شکسته، A02 پیکربندی نادرست، A03 شکست زنجیرهٔ تأمین نرم‌افزار، A04 شکست رمزنگاری، A05 تزریق، A06 طراحی ناامن، A07 شکست احراز هویت، A08 شکست یکپارچگی نرم‌افزار یا داده، A09 شکست ثبت و هشدار و A10 مدیریت نادرست شرایط استثنایی است. معنای عملی هر کدام برای فروشگاه (تفسیر نویسنده):

امنیت جریان پرداخت

سه قاعده از مستندات:

• ارتباط ایمن: Stripe استفاده از TLS/HTTPS را توصیه می‌کند؛ برای مبانی، SSL و HTTPS چیست؟ را ببینید.
• تأیید سمت سرور: مستند زرین‌پال می‌گوید verify فقط وقتی Status=OK است صدا زده می‌شود و مبلغ آن را از دیتابیس خودتان بگیرید. Stripe هم می‌گوید بدون تأیید امضا، مهاجم می‌تواند رویداد جعلی بفرستد تا سفارش فعال شود؛ پس امضا را با بدنهٔ خام و secret تأیید کنید و برای رد replay به timestamp توجه کنید.
• ارزش پایین‌دستی: فقط وقتی سفارش را «پرداخت‌شده» می‌کنید که تأیید سرور موفق باشد.

فرایندهای عملیاتی

1. دسترسی کارکنان: هر نفر حساب خودش، حداقل دسترسی، تأیید دومرحله‌ای برای مدیر، و حذف فوری دسترسی هنگام خروج. (توصیهٔ نویسنده.)
2. بک‌آپ: بک‌آپ منظم، رمزگذاری‌شده و بازیابی آزمایش‌شده؛ بک‌آپی که هرگز بازیابی نشده، فرضیه است نه بک‌آپ.
3. به‌روزرسانی: فهرست وابستگی‌ها و افزونه‌ها و زمان‌بندی به‌روزرسانی.
4. لاگ و هشدار: ورودهای ناموفق، تغییر مبلغ یا آدرس سفارش، خطاهای verify. مبانی پایش را در Monitoring چیست؟ ببینید.
5. پاسخ به حادثه: سند یک‌صفحه‌ای: چه کسی تصمیم می‌گیرد، چطور سایت را محدود کنیم، با درگاه و مشتریان چگونه ارتباط بگیریم. اینکه چه اعلامی قانوناً لازم است را از مشاور حقوقی بپرسید؛ این مقاله بررسی نکرده است.

چطور سنجیده شود؟

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

اشتباهات رایج

• «SSL دارد پس امن است».
• باور اینکه امنیت وظیفهٔ درگاه است و داده کارت در لاگ‌ها می‌ماند.
• تأیید سفارش فقط با بازگشت مرورگر.
• یک حساب مدیریتی مشترک.
• افزونه‌های قدیمی و رهاشده.
• بک‌آپ بدون آزمون بازیابی.
• پیام خطای فنی در صفحهٔ عمومی.

چک‌لیست

1. داده کارت از سرور شما رد نمی‌شود و در لاگ‌ها و فرم‌ها نیست.
2. بررسی مالکیت سفارش و آدرس در سرور برای همهٔ مسیرها انجام می‌شود.
3. HTTPS در کل سایت و پنل فعال است.
4. ورود مدیر با حداقل دسترسی و تأیید دومرحله‌ای است.
5. وابستگی‌ها و افزونه‌ها فهرست و به‌روز می‌شوند.
6. تأیید پرداخت سمت سرور است و مبلغ از دیتابیس می‌آید.
7. لاگ امنیتی و هشدار وجود دارد.
8. بک‌آپ و بازیابی آزمایش شده است.
9. الزامات انطباق و حقوقی از منبع رسمی روز و متخصص بررسی شده، نه از این مقاله.

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

منابع و مراجع

• OWASP Top 10:2025 — OWASP Foundation، 2025.
• Integration security guide — Stripe.
• Receive Stripe events in your webhook endpoint — Stripe.
• راهنمای اتصال به درگاه اینترنتی زرین‌پال — ZarinPal (مستندات رسمی).
• OWASP Application Security Verification Standard (ASVS) — OWASP Foundation.