امنیت فروشگاه‌ساز SaaS؛ حفاظت از سفارش، پرداخت و API

یک فروشگاه‌ساز SaaS ممکن است سرور و هسته پلتفرم را Patch کند، اما نمی‌تواند تشخیص دهد تخفیف ۹۰درصدی عمدی بوده، Refund را کارمند مجاز زده، App انبار واقعاً به کل فهرست مشتریان نیاز دارد یا Callback درگاه به سفارش درست وصل شده است. در تجارت الکترونیک، امنیت فقط «هک‌نشدن سایت» نیست؛ باید پول، سفارش، موجودی، داده مشتری و توان ادامه فروش هم‌زمان محافظت شوند.

پاسخ کوتاه: برای امن‌کردن فروشگاه‌ساز SaaS، دسترسی‌های مالی و عملیاتی را جدا کنید، جریان سفارش و پرداخت را State-based و قابل تطبیق نگه دارید، App/API/Webhook و اسکریپت صفحه پرداخت را موجودی‌برداری کنید، سوءاستفاده از Coupon و Inventory را پایش کنید و برای Account takeover، مغایرت پرداخت و اختلال فروش Runbook داشته باشید.

مرز این راهنما با امنیت عمومی سایت‌ساز

کنترل Owner، دامنه، DNS، Role، Backup/Export و Incident در همه سایت‌سازها مشترک است و در چک‌لیست امنیت سایت‌ساز SaaS آمده است. این مقاله روی ریسک‌های اختصاصی تجارت الکترونیک تمرکز دارد: تغییر قیمت و موجودی، تصاحب حساب مشتری، سوءاستفاده از تخفیف، پرداخت و تسویه، سفارش و مرجوعی، زنجیره Appها و APIهایی که عملیات فروش را به هم متصل می‌کنند.

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

ابتدا دارایی و اثر کسب‌وکار را مشخص کنید

هر سناریو را با «احتمال × اثر» اولویت بدهید. تغییر یک تصویر وبلاگ با تغییر حساب تسویه برابر نیست. کنترل‌های سخت‌گیرانه‌تر باید دور عملیات برگشت‌ناپذیر یا پراثر قرار گیرند.

۱. نقش‌های فروشگاه را بر اساس تضاد وظایف بسازید

فقط دو نقش «Admin» و «کارمند» برای فروشگاه کافی نیست. کسی که محصول می‌سازد لزوماً نباید درگاه یا Refund را تغییر دهد؛ فردی که سفارش را بسته‌بندی می‌کند به Export کامل مشتری نیاز ندارد.

برای تغییر حساب تسویه، Gateway، Admin، App پرمجوز، Export انبوه و Refund بزرگ، اصل چهارچشم را اجرا کنید: یک نفر درخواست و فرد دیگری تأیید کند. اگر پلتفرم Approval داخلی ندارد، Ticket و اعلان مستقل کنترل جبرانی هستند.

ورود Owner، Admin مالی و تیم پشتیبانی باید با MFA و Recovery کنترل‌شده محافظت شود. جزئیات Passkey، TOTP، Session و Break-glass در راهنمای MFA پنل مدیریت آمده است.

۲. حساب مشتری را بدون تخریب تجربه خرید محافظت کنید

حساب مشتری ممکن است نشانی، تاریخچه سفارش، اعتبار، امتیاز وفاداری یا روش‌های پرداخت Tokenized داشته باشد. مهاجم با Credential stuffing می‌تواند از رمزهای لو‌رفته سرویس‌های دیگر استفاده کند. دفاع باید چندلایه و متناسب با ریسک باشد.

• رمزهای شناخته‌شده لو‌رفته را در صورت پشتیبانی پلتفرم Block کنید و رمز تکراری را تشویق نکنید.
• Rate limit را بر IP تنها بنا نکنید؛ Account، Device، ASN و الگوی رفتاری را نیز در نظر بگیرید.
• برای تغییر ایمیل، تلفن، نشانی حساس، Redeem اعتبار و عملیات مالی Step-up authentication بخواهید.
• پیام خطای Login و Recovery نباید وجود حساب را ساده افشا کند.
• اعلان ورود جدید، تغییر مشخصات و سفارش غیرعادی را با مسیر گزارش سریع ارسال کنید.
• Guest checkout را با مدل محصول بسنجید؛ اجبار ساخت حساب همیشه امنیت را بیشتر نمی‌کند.

CAPTCHA یک کنترل کمکی است، نه درمان اصلی. طراحی Lockout، False positive و پاسخ به تصاحب حساب را در راهنمای دفاع Brute Force و Credential Stuffing کامل کنید.

۳. منطق قیمت، تخفیف و موجودی را به ورودی مرورگر اعتماد ندهید

قیمت نهایی، تخفیف، هزینه ارسال، مالیات و موجودی باید در سمت سرویس معتبر دوباره محاسبه شوند. نمایش مبلغ در Browser یا Mobile app مدرک معتبر نیست. در SaaS ممکن است کد این بخش در اختیار فروشنده باشد، اما تنظیم Rule، Permission و تست سناریو با صاحب فروشگاه است.

سوءاستفاده‌های رایج کسب‌وکاری

• استفاده چندباره از Coupon تک‌مصرف با هم‌زمانی درخواست‌ها؛
• ترکیب تخفیف‌هایی که قرار نبوده Stack شوند؛
• رزرو موجودی با سبدهای رهاشده یا Bot؛
• خرید انبوه کالای محدود و محروم‌کردن مشتری واقعی؛
• تغییر Quantity، Variant یا Price در Request؛
• استفاده از Referral یا اعتبار روی حساب‌های ساختگی.

برای هر Promotion محدودیت Account، Device، زمان، موجودی، تعداد و بودجه تعریف کنید. صرف Rate limit ممکن است مشتریان پشت IP مشترک را مسدود کند؛ بنابراین سیگنال چندبعدی، سقف زیان و Review دستی برای موارد مرزی لازم است.

۴. پرداخت را یک State machine بدانید، نه یک صفحه موفق

Redirect موفق کاربر، Screenshot رسید یا پارامتر Browser نباید سفارش را Paid کند. وضعیت باید پس از Verify سمت سرور با ارائه‌دهنده پرداخت و تطبیق Merchant، Amount، Currency و شناسه یکتا تغییر کند.

1. سفارش با مبلغ محاسبه‌شده در Server ساخته و یک Payment attempt مستقل ایجاد شود.
2. کاربر به درگاه معتبر هدایت شود؛ Secret در Browser قرار نگیرد.
3. Return فقط تجربه کاربر را ادامه دهد، نه اینکه به‌تنهایی منبع حقیقت باشد.
4. Webhook/Callback امضا یا Secret، Timestamp و Replay protection داشته باشد.
5. Verify سمت سرور نتیجه را از ارائه‌دهنده بگیرد و Amount/Order را تطبیق دهد.
6. تغییر وضعیت با Idempotency انجام شود تا Callback تکراری سفارش را دوبار اعمال نکند.
7. وضعیت‌های Unknown و Pending به صف Reconciliation بروند، نه Success یا Failed حدسی.

معماری Callback، Idempotency، Race condition، تومان/ریال و Reconciliation در راهنمای اتصال امن درگاه پرداخت با جزئیات فنی آمده است.

۵. صفحه پرداخت را از E-skimming و Script اضافی پاک نگه دارید

حتی اگر ورود داده کارت روی صفحه میزبانی‌شده درگاه انجام شود، صفحه Checkout می‌تواند با Script، Redirect یا محتوای فریبنده بر تصمیم کاربر اثر بگذارد. PCI SSC در راهنمای مرتبط با PCI DSS ۴.۰.۱ بر مجازبودن، توجیه و کنترل یکپارچگی Scriptهای صفحه پرداخت و تشخیص تغییر تأکید می‌کند. این جمله به معنی «PCI compliant بودن خودکار» فروشگاه شما نیست؛ Scope و روش اعتبارسنجی را با پذیرنده، Acquirer یا مشاور واجد صلاحیت تعیین کنید.

• فهرست همه Scriptهای Checkout، مالک، هدف و Domain آن‌ها را نگه دارید.
• Pixel، Chat، Heatmap و Tag غیرضروری را از مسیر پرداخت حذف یا محدود کنید.
• اگر پلتفرم CSP، SRI یا Tamper detection ارائه می‌دهد، آن را در محیط Test و سپس Rollout کنترل‌شده فعال کنید.
• تغییر Script، Header، Theme و مقصد لینک پرداخت را اعلان‌دار کنید.
• صفحه نتیجه پرداخت را نیز بررسی کنید؛ نمایش داده حساس یا جزئیات Debug ممنوع باشد.

۶. API را با Inventory، Scope و تست Authorization اداره کنید

فروشگاه SaaS معمولاً به انبار، CRM، پیامک، حسابداری، ارسال، مارکت‌پلیس و BI متصل است. هر اتصال یک مسیر داده و عملیات می‌سازد. OWASP API Security Top ۱۰ (نسخه ۲۰۲۳) ضعف Authorization سطح Object/Property/Function، مصرف نامحدود منابع، Inventory ناقص و اعتماد ناامن به API ثالث را از ریسک‌های اصلی می‌داند.

کنترل Token و کلید

• برای هر Integration یک Credential جدا با Scope حداقلی بسازید؛ کلید مشترک تیمی نسازید.
• Secret را در Repository، Theme، Browser، Spreadsheet یا پیام‌رسان ذخیره نکنید.
• تاریخ صدور، مالک، Scope، آخرین استفاده، Rotation و Revoke را ثبت کنید.
• محیط Test و Production، Merchant و Callback URL را جدا نگه دارید.
• هنگام حذف App، Token، Webhook و Service account را مستقل لغو کنید.

تست Authorization و داده

برای Endpoint سفارش یا مشتری فقط «ورود موفق» را تست نکنید. بررسی کنید User A با تغییر Order ID نتواند سفارش User B را ببیند؛ نقش انبار نتواند Refund بزند؛ Response فقط Property لازم را برگرداند؛ و عملیات Bulk سقف، Pagination و Approval داشته باشد.

فهرست نسخه API و Endpointها را نگه دارید. نسخه Deprecated، Debug endpoint و Webhook قدیمی بدهی امنیتی‌اند—even اگر در UI دیده نشوند.

۷. Webhook را یک درخواست خصمانه فرض کنید

Webhook از بیرون به سیستم شما می‌آید و ممکن است تکرار، جابه‌جا یا جعل شود. IP allowlist به‌تنهایی کافی نیست؛ Provider ممکن است IP را تغییر دهد و Proxy نیز مسیر را عوض کند.

• امضا را روی Raw body و طبق الگوریتم رسمی Provider بررسی کنید.
• Timestamp و پنجره زمانی برای کاهش Replay داشته باشید.
• Event ID را برای Idempotency ذخیره کنید.
• پردازش را سریع Acknowledge و کار سنگین را به Queue منتقل کنید.
• Schema، نوع Event و Merchant/Shop ID را Validate کنید.
• ترتیب Eventها را قطعی فرض نکنید؛ State فعلی را پیش از اعمال تغییر بخوانید.
• Payload کامل حاوی داده حساس را بی‌محابا در Log نریزید.

۸. Appهای فروشگاهی را بر اساس دامنه اثر ارزیابی کنید

App ارسال، وفاداری یا Marketing ممکن است به Customer، Order و Product دسترسی Read/Write داشته باشد. Marketplace رسمی ریسک را کاهش می‌دهد اما حذف نمی‌کند. Review و تعداد نصب جای Scope، قرارداد داده و تست خروج را نمی‌گیرد.

هر فصل Appهای بدون استفاده را حذف و Scope بقیه را بازبینی کنید. قبل و بعد نصب App، Checkout، Order، Email، Webhook، سرعت و Export را با داده آزمایشی بسنجید.

۹. داده مشتری را کمینه و جریان آن را ترسیم کنید

فروشگاه معمولاً نام، تلفن، نشانی، تاریخچه خرید، پیام پشتیبانی و گاهی داده‌های حساس‌تر دارد. «داده داخل پلتفرم است» به معنی نبود مسئولیت نیست. باید بدانید داده از فرم به کدام App، ایمیل، CRM، فایل و حساب کاربری می‌رود.

• هر فیلد را به هدف کسب‌وکار، مدت نگهداری و نقش مجاز متصل کنید.
• صفحه Admin و Export را بر اساس نیاز Mask و محدود کنید.
• فایل CSV مشتری را رمزگذاری، زمان‌دار و پس از مصرف حذف کنید.
• داده Production را بدون Masking به محیط Test یا پیمانکار ندهید.
• درخواست حذف/اصلاح و Incident داده را با فرایند حقوقی کسب‌وکار هماهنگ کنید.
• Log نباید Secret، Session، داده پرداخت یا PII غیرضروری را نگه دارد.

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

۱۰. Refund، مرجوعی و تغییر سفارش را به اندازه پرداخت جدی بگیرید

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

• Refund را به Order و Payment attempt اصلی متصل و مبلغ تجمعی را محدود کنید.
• برای Refund بزرگ یا خارج از بازه، Approval دوم و Reason code اجباری باشد.
• تغییر نشانی پس از Paid شدن، اعلان به مشتری و Audit trail داشته باشد.
• کارمند پشتیبانی نتواند هم درخواست و هم تأیید جبران مالی را انجام دهد.
• Refund پلتفرم، درگاه و حسابداری را روزانه تطبیق دهید.
• افزایش Return، Coupon یا Gift-card redemption را بر Segment و اپراتور پایش کنید.

۱۱. Availability فقط DDoS نیست

فروشنده SaaS بخش مهمی از ظرفیت شبکه و مقابله با DDoS را مدیریت می‌کند، اما سوءاستفاده از Business flow می‌تواند بدون ترافیک عظیم فروش را مختل کند: Bot موجودی را رزرو می‌کند، OTP هزینه پیامک می‌سازد، Search سنگین منابع را مصرف می‌کند یا Coupon budget را می‌سوزاند.

Rate limit باید Endpoint و عملیات‌محور باشد. سقف رزرو موجودی، زمان آزادسازی سبد، حد OTP، Pagination، File size و Spending alert سرویس‌های ثالث را مشخص کنید. OWASP نیز مصرف نامحدود منابع را علاوه بر DoS، عامل افزایش هزینه سرویس‌هایی مانند SMS می‌داند.

اگر پلتفرم اجازه لایه Edge یا Rule سفارشی می‌دهد، انتخاب و Tuning را با راهنمای WAF سایت انجام دهید. WAF منطق غلط Refund یا Coupon را نمی‌فهمد و جای کنترل کسب‌وکاری نیست.

۱۲. لاگ و Detection را به زیان قابل اقدام وصل کنید

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

Baseline را با داده خودتان بسازید؛ عدد ثابت جهانی معمولاً False positive می‌سازد. هشدار باید روی کانالی بیرون از همان حساب فروشگاه نیز برسد تا تصاحب حساب آن را خاموش نکند.

۱۳. Reconciliation کنترل امنیتی و مالی است

گزارش فروشگاه، گزارش درگاه و دفتر مالی ممکن است به‌خاطر Retry، Timeout، Refund یا خطای انسانی اختلاف داشته باشند. تطبیق منظم کمک می‌کند هم خطای عملیاتی و هم سوءاستفاده کشف شود.

1. برای هر Payment attempt شناسه‌های Order، Provider و مبلغ/واحد پول را نگه دارید.
2. Paid بدون تراکنش معتبر، تراکنش موفق بدون Order paid، Refund نامتوازن و مبلغ متفاوت را استخراج کنید.
3. موارد Unknown را با Verify مستقل و Runbook تعیین تکلیف کنید.
4. اصلاح دستی باید Actor، دلیل، مدرک و Approval داشته باشد.
5. Settlement نهایی را نیز با مجموع تراکنش و Fee تطبیق دهید.

در فروشگاه ایرانی، تفاوت ریال و تومان را در Schema، UI، Log و تست صریح کنید. تبدیل ضمنی یا دوگانه می‌تواند اختلافی بسازد که شبیه تقلب دیده شود یا برعکس، تقلب را پنهان کند.

۱۴. Backup فروشگاه باید سفارش زنده را در نظر بگیرد

بازیابی فروشگاه با برگرداندن چند صفحه تمام نمی‌شود. هنگام Restore ممکن است سفارش و پرداخت جدید در سیستم اصلی ایجاد شده باشد. باید بدانید Snapshot چه داده‌ای را پوشش می‌دهد و چگونه سفارش‌های بعد از نقطه بازیابی Reconcile می‌شوند.

• RPO جدا برای Product، Customer، Order، Payment و Content تعریف کنید.
• Export دوره‌ای را باز و Schema آن را کنترل کنید.
• App config، Automation، Redirect، Theme و Media را در بسته خروج لحاظ کنید.
• تمرین Restore را با سفارش ساختگی و سناریوی Payment pending اجرا کنید.
• پس از Cutover، سفارش و تراکنش بازه شکاف را تطبیق دهید.

برای معماری Backup مستقل، RPO/RTO و تمرین بازیابی از راهنمای بازیابی فاجعه سایت استفاده کنید.

۱۵. چهار Runbook اختصاصی فروشگاه آماده کنید

تصاحب حساب Admin یا مشتری

Session و Token را Revoke کنید، Recovery و تغییرات اخیر را ببینید، عملیات مالی را موقتاً محدود کنید، Customer/Order/Export تحت اثر را مشخص و سپس دسترسی را بازگردانید.

تغییر غیرمجاز Price، Gateway یا Refund

انتشار یا عملیات پرریسک را Pause کنید، قبل/بعد و Actor را حفظ کنید، سفارش‌های بازه اثر را استخراج، مقصد پرداخت و Settlement را کنترل و اصلاح را با Approval اجرا کنید.

پرداخت موفق و سفارش نامشخص

به Return مرورگر اعتماد نکنید؛ Verify و Provider reference را بررسی کنید، سفارش را در صف Unknown نگه دارید، از ایجاد سفارش تکراری جلوگیری و نتیجه را به مشتری شفاف اطلاع دهید.

نشت داده یا App مشکوک

App و Token را مهار کنید، Log و Export را حفظ کنید، دامنه داده و بازه رخداد را تعیین کنید، با فروشنده و مسئول حقوقی هماهنگ شوید و قبل از وعده قطعی، بررسی را کامل کنید.

چگونه فروشگاه‌ساز SaaS را پیش از خرید ارزیابی کنیم؟

به هر مورد ۰ تا ۳ بدهید و برای معیار حیاتی حداقل اجباری بسازید. میانگین امتیاز بالا نباید نبود Audit مالی یا Export سفارش را پنهان کند. مدرک، Screenshot و نتیجه تست را کنار پاسخ فروشنده نگه دارید.

ملاحظات فروشگاه اینترنتی در ایران

• واحد پول: ریال/تومان را در Product، Order، Gateway، Log و Reconciliation یکسان و صریح نگه دارید.
• درگاه: Return، Verify، Callback و تسویه را با Sandbox یا مبلغ کم و سناریوی Timeout تست کنید.
• پیامک: OTP و اعلان سفارش را Rate-limit کنید و برای افزایش هزینه/ارسال هشدار داشته باشید.
• انبار و ارسال: Retry یا قطعی Integration نباید سفارش را دوبار کم یا دوبار ارسال کند؛ Idempotency و Queue لازم است.
• تمدید و دسترسی: Billing پلتفرم، App و دامنه را مالک‌دار و زودتر از موعد پیگیری کنید.
• پشتیبانی: مسیر اضطراری، ساعت پاسخ و امکان دسترسی به Log را با رخداد آزمایشی بسنجید.
• خروج: Product، Customer، Order، Media، SEO و Automation را پیش از وابستگی عمیق Export و بررسی کنید.

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

برنامه ۳۰ روزه امن‌سازی فروشگاه‌ساز

روز ۱ تا ۷: پول و دسترسی

• Owner، Admin مالی، Gateway، Refund و Export را بازبینی کنید.
• MFA و Session policy را فعال و حساب مشترک را حذف کنید.
• تغییر Payout، Price انبوه و Refund بزرگ را Approval‌دار کنید.

روز ۸ تا ۱۴: App، API و Checkout

• App، Token، Webhook و Script را با Scope و مالک فهرست کنید.
• Checkout را از Tag غیرضروری پاک و مسیر Gateway را کنترل کنید.
• Authorization و Idempotency پنج جریان حیاتی را تست کنید.

روز ۱۵ تا ۲۱: Detection و تطبیق

• هشدار ورود Admin، Export، Refund، Price و Webhook failure بسازید.
• فروشگاه، درگاه و حسابداری را Reconcile کنید.
• تست مصنوعی خرید و برگشت از پرداخت را زمان‌بندی کنید.

روز ۲۲ تا ۳۰: بازیابی و رخداد

• Export واقعی بگیرید و یک Import/Restore محدود انجام دهید.
• چهار Runbook را Tabletop تمرین کنید.
• سه ریسک باقیمانده را به مالک، موعد، KPI و بودجه وصل کنید.

اگر برای Threat model، PoC فروشنده یا Runbook پرداخت به همراهی نیاز دارید، درخواست مشاوره امنیت فروشگاه را ثبت کنید.

سوالات متداول امنیت فروشگاه‌ساز SaaS

آیا فروشگاه‌ساز SaaS امنیت پرداخت را کامل بر عهده دارد؟

خیر. پلتفرم و ارائه‌دهنده پرداخت بخشی از زیرساخت و پردازش را اداره می‌کنند، اما تنظیم Gateway، حساب‌ها، Appها، Scriptها، Verify، Order state، Refund و Reconciliation همچنان به پیکربندی و عملیات فروشگاه وابسته‌اند.

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

Owner، Billing/Payout، Gateway، Refund، Customer export، App/API management و Catalog bulk change باید تا حد امکان نقش و Approval جدا داشته باشند.

چرا Callback موفق برای Paid کردن سفارش کافی نیست؟

Callback یا Return می‌تواند تکرار، جعل یا قطع شود. نتیجه باید سمت سرور Verify و Merchant، Amount، Currency و شناسه سفارش تطبیق داده شود؛ سپس تغییر State به‌شکل Idempotent انجام شود.

چطور App فروشگاهی را امن ارزیابی کنیم؟

Scope، نوع داده، امکان Write، Publisher، Subprocessor، Token، Log، پاسخ رخداد، حذف داده و Exit را بررسی و روی فروشگاه آزمایشی Checkout، Order، Webhook و Export را تست کنید.

آیا PCI DSS برای هر فروشگاه ایرانی الزامی است؟

دامنه و الزام به مدل پرداخت، قرارداد و طرف‌های درگیر بستگی دارد و باید با Acquirer/ارائه‌دهنده و متخصص ذی‌صلاح تعیین شود. می‌توان کنترل‌های امنیت صفحه پرداخت را به‌عنوان Benchmark به‌کار برد، اما این کار به‌تنهایی اثبات انطباق نیست.

جمع‌بندی

امنیت فروشگاه‌ساز SaaS جایی میان فناوری و عملیات مالی قرار دارد. Role و Approval، State سفارش، Verify و Reconciliation، App/API/Webhook، Script صفحه پرداخت، داده مشتری، Detection و Recovery باید یک سیستم واحد بسازند. از جریان پول و دسترسی‌های پراثر شروع کنید، ادعای پلتفرم را با PoC بسنجید و هر رخداد را به Runbook و سیگنال قابل اقدام متصل کنید.

منابع مرجع: OWASP API Security Top 10 2023، PCI SSC درباره امنیت صفحه پرداخت و E-skimming و NIST Cybersecurity Framework.