Odoo सिक्योरिटी

बैकअप/ गड़बड़ी रोकने के लिए रिकवरी

• हम हर Odoo डेटाबेस के कम से कम 3 महीने के लिए 14 फ़ुल बैकअप रखते हैं: 7 दिनों के लिए 1/दिन, 4 सप्ताह के लिए 1/सप्ताह, 3 महीने के लिए 1/महीना.
• बैकअप को कम से कम 2 अलग-अलग महाद्वीपों पर, कम से कम 3 अलग-अलग डेटा सेंटर में कॉपी किया जाता है.
• हमारे डेटा सेंटर कहां स्थित हैं, इसकी जानकारी यहां दी गई है: निजता नीति.
• आप कंट्रोल पैनल का इस्तेमाल करके किसी भी समय अपने लाइव डेटा का मैन्युअल बैकअप भी डाउनलोड कर सकते हैं.
• आप अपने लाइव डेटाबेस (या साइड पर) पर किसी भी बैकअप को रीस्टोर करने के लिए हमारे हेल्पडेस्क से संपर्क कर सकते हैं.
• हार्डवेयर फे़लओवर: हो सकता है कि फ़िजिकल सर्वर पर होस्ट की गई सेवाओं के लिए हार्डवेयर फ़ेल हो जाए. ऐसी स्थिति में हम डुप्लीकेट सर्वर पर तुरंत उसे चालू करते हैं. साथ ही, हम इसे पूरी तरह से मॉनिटर करते हैं और मैन्युअल फ़ेलओवर प्रक्रिया को भी चालू रखते हैं.
• गड़बड़ी रोकने के लिए रिकवरी: अगर सर्वर में गड़बड़ी हो जाए और डेटा सेंटर एक तय अवधि तक पूरी तरह से बंद हो जाए, तो डुप्लीकेट सर्वर में कोई गड़बड़ी ना आए (हालांकि, आज तक ऐसा कभी हुआ नहीं है. इससे ज़्यादा खराब स्थिति हो नहीं सकती है), इसके लिए हमारे पास कुछ प्लान है:
  • आरपीओ (रिकवरी पॉइंट ऑब्जेक्टिव) = 24 घंटे. इसका मतलब है कि अगर डेटा रिकवर नहीं हो पाता है और हमें आपका सबसे नया डेली बैकअप रीस्टोर करना पड़ता है, तो आप ज़्यादा से ज़्यादा 24 घंटे का काम खो सकते हैं.
  • आरटीओ (रिकवरी टाइम ऑब्जेक्टिव) = पैसे देकर ली गई सदस्यता वाले उपयोगकर्ताओं के लिए 24 घंटे और मुफ़्त में आज़माने वाले, शिक्षा से जुड़े ऑफ़र, फ्रीमियम उपयोगकर्ताओं वगैरह के लिए 48 घंटे. जब सर्वर में गड़बड़ी आने पर और डेटासेंटर पूरी तरह से बंद हो जाने पर, इतने समय में ही किसी दूसरे डेटा सेंटर में सेवा को रीस्टोर किया जाता है.
  • डेटा रिकवर कैसे किया जाता है: हम अपने रोजाना होने वाले बैकअप को लगातार मॉनिटर करते हैं और अलग-अलग महाद्वीपों में कई सारी जगहों पर डेटा को कॉपी किया गया है. हमने अपनी सेवाओं को होस्ट करने के लिए एक नए सर्वर पर अपने-आप कॉपी होने वाला सिस्टम सेट किया हुआ है. पिछले दिन के डेटा का बैकअप रीस्टोर कुछ ही घंटों किया जाता है. अगर बहुत सारा डेटा हो, तो भी इतना ही समय लगता है. हम पैसे चुकाकर सदस्यता लेने वाला सदस्यों के डेटा को प्राथमिकता देते हैं.
    हम रोजाना होने वाले कामों के लिए डेली बैकअप और प्रोविजनिंग स्क्रिप्ट, दोनों का नियमित रूप से इस्तेमाल करते हैं. इसलिए, गड़बड़ी को रोकने की प्रक्रिया की जांच भी उसी समय हो जाती है.

डेटाबेस की सुरक्षा

• ग्राहक के डेटा को खास तौर पर बनाए गए डेटाबेस में स्टोर किया जाता है. क्लाइंट के डेटा को एक-दूसरे के साथ शेयर नहीं किया जाता.
• डेटा ऐक्सेस कंट्रोल के नियम की वजह से एक ही क्लस्टर में डेटाबेस होने के बावजूद हर ग्राहक का डेटा निजी रखा जाता है. एक डेटाबेस से दूसरे डेटाबेस के डेटा को ऐक्सेस नहीं किया जा सकता.

पासवर्ड की सुरक्षा

• ग्राहक के पासवर्ड को इंडस्ट्री-स्टैंडर्ड PBKDF2+SHA512 एन्क्रिप्शन (सॉल्टेड + हजारों राउंड के लिए स्ट्रेच्ड) के साथ सुरक्षित किया जाता है.
• Odoo के कर्मचारी के पास आपका पासवर्ड ऐक्सेस नहीं होता है और वह इसे हासिल भी नहीं कर सकता है. अगर आप अपना पासवर्ड भूल जाते हैं, तो सिर्फ़ रीसेट करके ही दोबारा से पाया जा सकता है.
• लॉगिन क्रेडेंशियल हमेशा HTTPS पर सुरक्षित रूप से भेजे जाते हैं.
• ग्राहकों के डेटाबेस के एडमिन के पास विकल्प होता है कि वे कई बार लगातार लॉगिन करने परलॉगिन की सीमा तय कर दे और अगली बार लॉगिन करने के लिए समयसीमा लगा दे.
• पासवर्ड से जुड़ी नीतियां: डेटाबेस एडमिन के पास उपयोगकर्ता के पासवर्ड को कम से कम कितने वर्ण का रखा जा सकता है, इसके लिए पहले ही से ही एक सेटिंग मौजूद होती है. पासवर्ड से जुड़ी दूसरी नीतियों जैसे कि पासवर्ड के लिए वर्णों का एक खास क्रम होना डिफ़ॉल्ट तौर पर ज़रूरी नहीं है. ऐसा इसलिए, क्योंकि मुश्किल पासवर्ड रखने पर उपयोगकर्ता एक ही पैटर्न पर पासवर्ड बनाता है जिसे क्रैक करना आसान हो जाता है. उदाहरण के लिए, ये देखें:शॉ की 2016 की रिसर्चऔर NIST SP 800-63b.

कर्मचारी के लिए ऐक्सेस

• Odoo हेल्पडेस्क का कर्मचारी आपके खाते में साइन इन कर सकता है. हालांकि, वो ऐसा तभी कर पाएगा जब आपको ऐक्सेस सेटिंग से जुड़ी कोई मदद चाहिए होगी. इसके लिए वो आपका पासवर्ड नहीं, बल्कि खास तौर पर कर्मचारियों को मिलने वाले क्रेडेंशियल का इस्तेमाल करेगा. उनके पास आपका पासवर्ड जानने का कोई तरीका नहीं है.
• कर्मचारियों को खास तौर पर मिलने क्रेडेंशियल की वजह से ना सिर्फ़ सुरक्षा मज़बूत होती है, बल्कि इससे काम करने की क्षमता भी बढ़ती है: वे आपके सामने आने वाली समस्या को तुरंत हल कर सकते हैं और आपको उनके साथ पासवर्ड भी शेयर नहीं करना पड़ता है. हम कर्मचारी की गतिविधियों को अळग से ऑडिट कर सकते हैं और कंट्रोल भी कर सकते हैं!
• हेल्पडेस्क से जुड़ा हमारा कर्मचारी आपकी निजता का पूरी तरह से ध्यान रखता है. वो सिर्फ़ उन्हीं फ़ाइलों और सेटिंग को ऐक्सेस करता है जिनमें किसी गड़बड़ी को ठीक करना होता है.

सिस्टम सुरक्षा

• Odoo क्लाउड के सभी सर्वर अप-टू-डेट सुरक्षा पैच वाले Linux डिस्ट्रिब्यूशन पर चल रहे हैं.
• हम वही सॉफ़्टवेयर इंस्टॉल करते हैं जिसकी आपको ज़रूरत होती है और सेवाओं को भी सीमित रखते हैं, ताकि सुरक्षा से कोई समझौता न हो (उदाहरण के लिए, PHP/MySQL का इस्तेमाल नहीं किया जाता).
• Odoo के सिर्फ़ कुछ ही भरोसेमंद इंजीनियर को सर्वर को दूर से मैनेज करने की अनुमति है और एन्क्रिप्ट किए गए निजी एसएसएच कीपेयर का ही इस्तेमाल करके ऐक्सेस किया जा सकता है. यह काम भी फ़ुल-डिस्क एन्क्रिप्शन वाले कंप्यूटर से ही संभव है.

फिज़िकल सिक्योरिटी

Odoo क्लाउड सर्वर दुनिया के अलग-अलग क्षेत्रों (जैसे, OVH, Google Cloud) के भरोसेमंद डेटा सेंटर में होस्ट किए जाते हैं. इन डेटा सेंटर को हमारे फिज़िकल सिक्योरिटी से जुड़े इन मापदंडों से गुज़रना होगा:

• डेटा सेंटर में सिर्फ़ अधिकृत कर्मचारियों की एंट्री और कुछ खास लोगों को ही प्रवेश की अनुमति.
• सिक्योरिटी बैज या बायोमेट्रिक सिक्योरिटी होने पर ही डेटा सेंटर में किसी अधिकृत व्यक्ति का प्रवेश.
• सुरक्षा कैमरों की मदद से चौबीसों घंटे डेटा सेंटर वाली जगहों की निगरानी किया जाता हो.
• चौबीसों घंटे सुरक्षाकर्मी मौजूद हो.

क्रेडिट कार्ड की सुरक्षा

• हम कभी भी अपने सिस्टम पर क्रेडिट कार्ड की जानकारी स्टोर नहीं करते हैं.
• आपकी क्रेडिट कार्ड की जानकारी हमेशा आपके और हमारे PCI के नियम का पालनका पालन करने वाली पेमेंट कंपनी को सीधे सुरक्षित रूप से भेज दी जाती है. ( निजता नीति वाले पेज पर जाकर सूची देखें).

डेटा एन्क्रिप्शन

• क्लाइंट इंस्टेंस के लिए डेटा के ट्रांसफ़र को 256-बिट SSL एन्क्रिप्शन (HTTPS) के ज़रिए सुरक्षित किया जाता है.
• हमारे सर्वरों के बीच सभी इंटरनल डेटा का ट्रांसफ़र भी एंड-टू-एंड एन्क्रिप्शन के ज़रिए सुरक्षित है.
• हमारे सर्वरों को कड़ी सुरक्षा निगरानी में रखा जाता है और सबसे नए SSL में किसी भी तरह की दिक्कत ना आए, इसलिए हमेशा अपडेट किया जाता है.
• हमारे सभी SSL सर्टिफ़िकेट में मज़बूत 2048-बिट मॉड्यूल का इस्तेमाल किया जाता है जिसमें SHA-2 सर्टिफ़िकेट की चेन भी शामिल है. A+ रेटिंग
• ग्राहक का पूरा डेटा (डेटाबेस कॉन्टेंट और स्टोर की गई फ़ाइलें) को एक जगह स्टोर करके एन्क्रिप्ट किया जाता है. डेटा के इस्तेमाल और बैकअप (AES-256) के दौरान भी डेटा एन्क्रिप्ट ही रहते हैं.

नेटवर्क डिफ़ेंस

• Odoo क्लाउड जिन डेटा सेंटर का इस्तेमाल करता है उनके पास काफ़ी बड़ी नेटवर्क क्षमता है और उनको इस तरह डिज़ाइन किया गया है जिससे डिस्ट्रिब्यूटेड डेनियल ऑफ़ सर्विस (DDoS) के हमलों का भी सामना किया जा सके. ऑटोमैटिक और मैन्युअल तरीके से सुरक्षा करने वाले सिस्टम इस तरह काम करते हैं कि अगर किसी दूसरे महाद्वीप के नेटवर्क के ज़रिए भी हमला किया जाए, तो इससे उसका पता लगाया जा सकता है और उसे डायवर्ट किया जा सकता है, ताकि सेवा में किसी तरह की बाधा ना आए.
• Odoo क्लाउड सर्वर पर फ़ायरवॉल और हमले को रोकने वाली सिस्टम की मदद से, ब्रूट-फोर्स पासवर्ड के हमलों जैसे खतरों का पता लगाया जाता है और उनको हमला करने से पहले ही रोका जाता है.
• ग्राहकों के डेटाबेस के एडमिन के पास विकल्प होता है कि वे कई बार लगातार लॉगिन करने पर लॉगिन की सीमा तय कर दे और अगली बार लॉगिन करने के लिए समयसीमा लगा दे.

सॉफ़्टवेयर सिक्योरिटी

Odoo ओपन सोर्स है, इसलिए पूरा कोडबेस दुनिया भर में Odoo के उपयोगकर्ताओं और डेवलेपमेंट में योगदान देने वाले लोगों के ज़रिए लगातार इसकी जांच होती रहती है. इसलिए, इन कम्यूनिटी से मिलने वाले बग रिपोर्ट को हम सुरक्षा के लिहाज़ से सबसे अहम फ़ीडबैक मानते हैं. हम अपने डेवलपर को कोड का ऑडिट करने के लिए कहते हैं और सुरक्षा से जुड़ी समस्याओं को रिपोर्ट करने के लिए कहते हैं.

Odoo की रिसर्च और डेवलपमेंट प्रोसेस में कोड की समीक्षा के लिए कई चरण होते हैं जो सुरक्षा के लिहाज़ से काफ़ी ज़रूरी हैं. इस समीक्षा में इंटरनल टीम या बाहर से सहयोग देने वाले लोगों से मिले कोड की भी जांच की जाती है.

सुरक्षित डिज़ाइन

Odoo को इस तरह से डिज़ाइन किया गया है कि यह सुरक्षा से जुड़ी आम गड़बड़ियों को रोक देता है:

• SQL इंजेक्शन को ऐसे हाई-लेवल API का इस्तेमाल करके किसी भी खतरे को रोका जाता है जिसमें मैन्युअल तौर पर SQL क्वेरी की ज़रूरत नहीं होती है.
• XSS हमलों को ऐसे हाई-लेवल टेंप्लेट सिस्टम का इस्तेमाल करके रोका जाता है जो डेटा के तौर पर खतरनाक वर्णों को डालने पर इसे अपने-आप छोड़ देता है.
• यह फ्रेमवर्क इस तरह डिज़ाइन किया गया है जिससे प्राइवेट मेथड को RPC ऐक्सेस नहीं कर सकता है. इससे सुरक्षा कमियों का फ़ायदा उठाना मुश्किल हो जाता है.

यह भी देखें OWASP में बताई गईं मुख्य कमियां वाला सेक्शन भी देखें, ताकि यह जान सकें कि Odoo को इस तरह से शुरूआत से ही डिज़ाइन किया गया है जिससे कमियों को रोका जा सके.

स्वतंत्र सुरक्षा ऑडिट

Odoo का नियमित रूप से स्वतंत्र कंपनियों द्वारा ऑडिट किया जाता है जिन्हें हमारे ग्राहक और संभावित ग्राहक ऑडिट और पेनेट्रेशन टेस्ट करने के लिए नियुक्त करते हैं. Odoo की सुरक्षा टीम नतीजों के मिलने के बाद, जब भी ज़रूरत होती है, उसके हिसाब से बदलाव करती है.

हालांकि, हम इनमें से किसी भी परिणाम का खुलासा नहीं कर सकते, क्योंकि वे गोपनीय हैं और इसको कमिश्नर देखते हैं. कृपया ना पूछें ;-)

Odoo में स्वतंत्र तौर पर काम करने वाले सुरक्षा शोधकर्ताओं की एक ऐक्टिव कम्यूनिटी है. ये लगातार सोर्स कोड पर नज़र रखते हैं और Odoo की सुरक्षा को बेहतर बनाने और उसे मजबूत बनाने के लिए हमारे साथ काम करते हैं. हमारे सिक्योरिटी प्रोग्राम के बारे में यहां जानकारी मिलेगी: ज़िम्मेदारी से इस्तेमाल करने के निर्देश पेज पर मिल जाएगी.

OWASP में बताई गईं मुख्य कमियां

वेब ऐप्लिकेशन के लिए सुरक्षा से जुड़े सबसे बड़ी समस्याओं से Odoo कैसे निटपता है, ओपन वेब ऐप्लिकेशन सिक्योरिटी प्रोजेक्ट (OWASP) में बताया गया है:

• इंजेक्शन में आने वाली दिक्कतें: इंजेक्शन में आने वाली दिक्कत, खास तौर पर SQL इंजेक्शन की समस्या वेब ऐप्लिकेशन में बहुत आम है. इंजेक्शन तब होता है जब उपयोगकर्ता द्वारा दिया गया डेटा किसी कमांड या क्वेरी के भाग के रूप में इंटरप्रेटर को भेजा जाता है. हमलावर ने जिस डेटा के साथ छेड़छाड़ की है उससे इंटरप्रेटर को गलत मैसेज मिल सकता है. जैसे, ऐसे कमांड फ़ॉलो करना या फिर डेटा में बदलाव करना.

  Odoo, ऑब्जेक्ट-रिलेशनल-मैपिंग (ORM) फ्रेमवर्क पर निर्भर करता है जो डिफ़ॉल्ट तौर पर क्वेरी बिल्डिंग को आसान बना देता है और SQL इंजेक्शन को रोक देता है. डेवलपर्स आमतौर पर SQL क्वेरीज़ को मैन्युअल रूप से तैयार नहीं करते हैं, वे ORM के ज़रिए जनरेट होते हैं, और पैरामीटर हमेशा ठीक से बच जाते हैं.

• क्रॉस साइट स्क्रिप्टिंग (XSS): XSS की दिक्कतें तब आती हैं जब कोई ऐप्लिकेशन उपयोगकर्ता के दिए गए गए डेटा को लेता है और उस कॉन्टेंट की पुष्टि या एनकोडिंग किए बना ही उसे वेब ब्राउज़र पर भेज देता है. XSS की वजह से हमलावर पीड़ित उपयोगकर्ता के ब्राउज़र में स्क्रिप्ट को एक्ज़ीक्यूट कर लेता है. इसका नुकसान यह होता है कि उपयोगकर्ता का पूरा सेशन हाईजैक हो सकता है, बेवसाइटें खराब हो सकती हैं, मैलवेयर भी फ़ैल सकता है.

  Odoo का फ्रेमवर्क डिफ़ॉल्ट तौर पर व्यू और पेज में रेंडर किए गए सभी एक्सप्रेशन से बच जाता है, जिससे XSS को रोका जा सकता है. डेवलपर्स को रेंडर किए पेज में रॉ इन्क्लूशन के लिए एक्सप्रेशन को खास तौर पर "सेफ़" के रूप में मार्क करना होगा.

• क्रॉस साइट रिक्वेस्ट फ़ोर्जरी (CSRF): CSRF के ज़रिए किया गया हमला लॉगिन करने वाले पीड़ित उपयोगकर्ता पीड़ित के ब्राउज़र को एक फ़र्ज़ी HTTP अनुरोध भेजने के लिए मज़बूर करता है. इसमें पीड़ित उपयोगकर्ता की सेशन कुकी और ऑटोमैटिक तौर पर पुष्टि की गई अन्य जानकारी शामिल होती है. यह जानकारी असुरक्षित वेब ऐप्लिकेशन को भेजी जाती है. इससे हमलावर को पीड़ित के ब्राउज़र को ऐसे अनुरोध जनरेट करने के लिए मज़बूर करने की अनुमति मिल जाती है जिन्हें सुरक्षा के लिहाज़ से कमजोर ऐप्लिकेशन को लगता है कि उपयोगकर्ता ने सही क्वेरी भेजी है.

  Odoo की वेबसाइट में पहले ही मौजूद CSRF सुरक्षा सिस्टम है. इससे किसी भी HTTP कंट्रोलर को संबंधित सुरक्षा टोकन के बिना POST अनुरोध प्राप्त करने से रोकता है. CSRF की गड़बड़ी से रोकने के लिए इस तकनीक को इस्तेमाल करने का सुझाव दिया जाता है. सुरक्षा वाला यह टोकन सिर्फ़ तभी मालूम और मौजूद होता है जब उपयोगकर्ता वास्तव में संबंधित वेबसाइट फ़ॉर्म तक पहुंचता है और कोई भी हमलावर इस टोकन के बिना अनुरोध नहीं कर सकता है.

• मैलवेयर वाली फ़ाइल का एक्ज़ीक्यूशन: रिमोट फ़ाइल इन्क्लूज़न (RFI) के लिए संवेदनशील कोड की मदद से हमलावर कोड और डेटा में छेड़छाड़ कर सकता है. इसका नुकसान यह होता है कि पूरा सर्वर बंद होने जैसी घटना भी हो सकती है. 

  Odoo, रिमोट फ़ाइल इन्क्लूज़न को परफ़ॉर्म करने का मौका नहीं देता है. हालांकि, ऐसे उपयोगकर्ताओं जिन्हें खास अधिकार मिला हुआ है उन्हें सुविधाओं में बदलाव करने का मौका मिलता है. इसके लिए उन्हें अपने खुद का बनाया हुआ एक्सप्रेशन डालना होगा जिसकी जांच सिस्टम करेगा. इन तरह के एक्सप्रेशन की जांच हमेशा सैंडबॉक्स और क्लीन सैनिटाइज़ सिस्टम के ज़रिए की जाती है, जो सिर्फ़ अनुमति फ़ंक्शन को ही ऐक्सेस करते हैं.

• असुरक्षित डायरेक्ट ऑब्जेक्ट रेफ़रंस: डायरेक्ट ऑब्जेक्ट रेफ़रंस तब होता है जब कोई डेवलपर किसी इंटरनल इंप्लिमेंटेशन ऑब्जेक्ट जैसे कि फ़ाइल, डायरेक्ट्री, डेटाबेस रिकॉर्ड या कुंजी को यूआरएल या फ़ॉर्म पैरामीटर के तौर पर दिखाता है. हमलावर बिना किसी अनुमति के अन्य ऑब्जेक्ट को ऐक्सेस करने के लिए इन रेफ़रंस में गड़बड़ी कर सकते हैं.

  Odoo ऐक्सेस कंट्रोल को यूजर इंटरफ़ेस लेवल पर लागू नहीं किया गया है, इसलिए यूआरएल में इंटरनल ऑब्जेक्ट के रेफ़रंस को दिखाने में कोई जोखिम नहीं है. हमलावर उन रेफ़रंस में गड़बड़ी करके ऐक्सेस कंट्रोल लेयर में कोई गड़बड़ी नहीं कर सकते हैं, क्योंकि हर अनुरोध को डेटा ऐक्सेस करने के लिए पुष्टि करने के बाद ही अनुमति मिलती है.

• असुरक्षित क्रिप्टोग्राफ़िक स्टोरेज: वेब ऐप्लिकेशन डेटा और क्रेडेंशियल की सुरक्षा के लिए क्रिप्टोग्राफ़िक फ़ंक्शन का शायद ही कभी सही तरीके से इस्तेमाल करते हैं. हमलावर पहचान की चोरी और क्रेडिट कार्ड धोखाधड़ी जैसे अन्य अपराधों को अंजाम देने के लिए ऐसे डेटा का इस्तेमाल करते हैं जो सुरक्षा के लिहाज़ से कमजोर है.

  Odoo उपयोगकर्ता पासवर्ड के लिए इंडस्ट्री-स्टैंडर्ड वाले सिक्योर हैशिंग (डिफ़ॉल्ट रूप से PBKDF2 + SHA-512, कुंजी स्ट्रेचिंग के साथ) का इस्तेमाल करता है, ताकि सेव किए पासवर्ड की सुरक्षा की जा सके. उपयोगकर्ता के पासवर्ड को स्थानीय तौर पर सेव करने से बचने के लिए, OAuth 2.0 या LDAP जैसे बाहरी ऑथेंटिकेशन सिस्टम का भी इस्तेमाल किया जा सकता है. 

• असुरक्षित कम्यूनिकेशन: जब संवेदनशील कम्यूनिकेशन की सुरक्षा करना ज़रूरी होती है, तो अक्सर ऐसा होता है कि ऐप्लिकेशन नेटवर्क ट्रैफ़िक को एन्क्रिप्ट करने में फे़ल हो जाते हैं.

  Odoo क्लाउड डिफ़ॉल्ट रूप से HTTPS पर चलता है. ऑन-प्रिमाइसेस इंस्टॉलेशन के लिए, Odoo को एन्क्रिप्शन और प्रॉक्सीइंग अनुरोध को लागू करने वाले वेब सर्वर के पीछे चलाने की सलाह दी जाती है, उदाहरण के लिए Apache, Lighttpd या nginx. Odoo को डिप्लाइ करने वाली गाइड में सिक्योरिटी चेकलिस्ट सुरक्षित पब्लिक डिप्लॉयमेंट के लिए इसके बारे में बताया गया है:

• यूआरएल ऐक्सेस को प्रतिबंधित करने में कामयाब नहीं: अक्सर ऐप्लिकेशन अनुमति ना मिलने वाले उपयोगकर्ताओं के लिंक या यूआरएल के दिखने को रोककर संवेदशनशील फ़ंक्शन की सुरक्षा करता है. हमलावर इस कमजोरी का इस्तेमाल करके उन यूआरआल को डायरेक्ट तौर पर ऐक्सेस करके ऐसी गतिविधियां कर सकते हैं जिसके लिए उन्हें अनुमति नहीं होती है. 

  Odoo ऐक्सेस कंट्रोल को यूजर इंटरफ़ेस के लेवल पर लागू नहीं किया गया है और सुरक्षा के लिए बनाया गया सिस्टम खास तरह के यूआरएल को छिपाने पर जैसी चीज़ों पर निर्भर नहीं करती है. हमलावर किसी भी यूआरएल का दोबारा इस्तेमाल करके या इसमें किसी तरह की हेरफेर करके ऐक्सेस कंट्रोल लेयर में कोई गड़बड़ी नहीं कर सकते हैं, क्योंकि हर अनुरोध को डेटा ऐक्सेस करने के लिए पुष्टि करने के बाद ही अनुमति मिलती है. कुछ खास तरह के मामलों में जिसमें यूआरएल के ज़रिए संवेदनशील डेटा को बिना अनुमति के ऐक्सेस किया जा सकता है, जैसे कि खास तरह के यूआरएल जिसका इस्तेमाल ग्राहक ऑर्डर की पुष्टि करने के लिए करता है. ऐसे यूआरएल यूनिक टोकन के साथ डिजिटल तौर पर साइन किए जाते हैं और सिर्फ़ उनको ही भेजा जाता है जिनको आप भेजना चाहते हैं. 

सुरक्षा की कमियों के बारे में रिपोर्टिंग

अगर आपको सुरक्षा से जुड़ी कमियों के बारे में कोई शिकायत करनी है, तो कृपया इस पेज पर जाएं: ज़िम्मेदारी से इस्तेमाल करने के निर्देश वाले पेज. इन शिकायतों को ज़्यादा प्राथमिकता दी जाती है, समस्या को तुरंत देखा जाता है और शिकायत करने वाले उपयोगकर्ता से बात करके Odoo की सुरक्षा टीम इसका हल निकालती है. इसके बाद Odoo के ग्राहकों और उपयोगकर्ताओं को ज़िम्मेदारी से इसके बारे में बताया जाता है.