आपका SaaS पैसा गंवा रहा है
अधिकांश डेवलपर्स अपना SaaS लॉन्च करते हैं और आगे बढ़ जाते हैं। वे सुरक्षा को बाद के लिए एक कार्य के रूप में देखते हैं। वे वास्तविक उपयोगकर्ताओं या वास्तविक पैसे के आने का इंतज़ार करते हैं।
वास्तविक वित्तीय नुकसान अक्सर सरल गलतियों से होते हैं। ये कोई जटिल हैक्स नहीं हैं। ये आपके कोड में लॉजिक एरर (logic errors) हैं।
यहाँ चार सामान्य तरीके दिए गए हैं जिनसे आप पैसा गंवाते हैं:
- क्रेडिट सिस्टम में रेस कंडीशंस (Race Conditions) आप यूजर का बैलेंस पढ़ते हैं, उसकी जांच करते हैं, और फिर नया बैलेंस लिखते हैं। यदि कोई यूजर एक ही समय में दो रिक्वेस्ट भेजता है, तो पहली रिक्वेस्ट द्वारा डेटाबेस अपडेट करने से पहले दोनों रिक्वेस्ट चेक पास कर सकती हैं। आप एक की कीमत में दो सेवाएं दे देते हैं।
समाधान: एटॉमिक डेटाबेस ऑपरेशन्स (atomic database operations) का उपयोग करें। पढ़ने और फिर लिखने के बजाय, केवल तभी बैलेंस अपडेट करने के लिए एक सिंगल कमांड का उपयोग करें जब यूजर के पास पर्याप्त क्रेडिट हों।
- पहचान के लिए क्लाइंट इनपुट पर भरोसा करना आप चेकआउट के दौरान रिक्वेस्ट बॉडी से ईमेल एड्रेस लेते हैं। एक ऑथेंटिकेटेड यूजर उस ईमेल को किसी और के एड्रेस में बदल सकता है। इससे वे गलत अकाउंट्स के लिए बिलिंग सेशन बना सकते हैं या आपके सिस्टम की जांच कर सकते हैं।
समाधान: रिक्वेस्ट बॉडी से पहचान पर कभी भरोसा न करें। अपने सर्वर पर वेरिफाइड सेशन टोकन (verified session token) से ईमेल निकालें।
- वार्षिक बिलिंग लॉजिक में खामी कई डेवलपर्स Stripe पेमेंट इवेंट्स को सुनकर यूजर क्रेडिट को रीसेट करते हैं। यह मंथली प्लान के लिए काम करता है। यह एनुअल प्लान के लिए विफल हो जाता है। Stripe प्रति वर्ष केवल एक इवेंट भेजता है। आपके यूजर्स को पहले दिन क्रेडिट मिल जाते हैं और अगले ग्यारह महीनों तक कुछ नहीं मिलता।
समाधान: क्रेडिट रीसेट को बिलिंग इवेंट्स से अलग (decouple) करें। यह जांचने के लिए कि किन यूजर्स को रीसेट डेट के आधार पर रीसेट की आवश्यकता है, एक डेली क्रॉन जॉब (daily cron job) का उपयोग करें।
- असुरक्षित टोकन स्टोरेज (Insecure Token Storage) आप पासवर्ड रीसेट टोकन को localStorage में स्टोर करते हैं। आपके पेज पर मौजूद कोई भी स्क्रिप्ट localStorage को एक्सेस कर सकती है। इसमें ब्राउज़र एक्सटेंशन और थर्ड-पार्टी एनालिटिक्स शामिल हैं।
समाधान: रिकवरी टोकन को संभालने के लिए अपने ऑथेंटिकेशन SDK का उपयोग करें। लाइब्रेरी को टोकन को लोकल स्टोरेज में स्टोर किए बिना स्वचालित रूप से प्रोसेस करने दें।
समस्या हमेशा एक ही होती है: आप क्लाइंट पर भरोसा करते हैं। आप भरोसा करते हैं कि रिक्वेस्ट एक-एक करके आती हैं। आप भरोसा करते हैं कि बिलिंग इवेंट्स हर मामले को कवर करते हैं।
इन समस्याओं को ठीक करने में एक दिन से भी कम समय लगता है। पैसा गंवाने से पहले अपने कोड का ऑडिट करें।
स्रोत: https://dev.to/manolito99/your-saas-is-probably-leaking-money-right-now-and-you-dont-know-it-1g38