Odoo Security

Backups / Disaster Recovery

• We keep 14 full backups of each Odoo database for up to 3 months: 1/day for 7 days, 1/week for 4 weeks, 1/month for 3 months.
• Backups are replicated in at least 3 different data centers, on at least 2 different continents.
• The actual locations of our data centers are specified in our Політика конфіденційності.
• You can also download manual backups of your live data at any time using the control panel.
• You can contact our Helpdesk to restore any of those backups on your live database (or on the side).
• Відмова апаратного забезпечення: для служб, розміщених на «голому металі», де можливий збій апаратного забезпечення, ми впроваджуємо реплікацію локального гарячого резерву з моніторингом і ручною процедурою перемикання після відмови, яка займає менше 5 хвилин.
• Аварійне відновлення: у разі повної катастрофи, коли центр обробки даних повністю не працюватиме на тривалий період, запобігаючи переключенню збоїв на наш локальний гарячий резерв (поки що такого не траплялося, це найгірший варіант), ми маємо такі цілі:
  • RPO (Recovery Point Objective) = 24h. This means you can lose max 24h of work if the data cannot be recovered and we need to restore your latest daily backup.
  • RTO (Recovery Time Objective) = 24h for paid subscriptions, 48h for free trials, education offer, freemium users, etc. This is the time to restore the service in a different data center if a disaster occurs and a datacenter is completely down.
  • How is this accomplished: we actively monitor our daily backups, and they are replicated in multiples locations on different continents. We have automated provisioning to deploy our services in a new hosting location. Restoring the data based on our backups of the previous day can then be done in a few hours (for the largest clusters), with priority on the paid subscriptions.
    We routinely use both the daily backups and provisioning scripts for daily operations, so both parts of the disaster recovery procedure are tested all the time.

Database Security

• Customer data is stored in a dedicated database - no sharing of data between clients.
• Data access control rules implement complete isolation between customer databases running on the same cluster, no access is possible from one database to another.

Password Security

• Customer passwords are protected with industry-standard PBKDF2+SHA512 encryption (salted + stretched for thousands of rounds).
• Odoo staff does not have access to your password, and cannot retrieve it for you, the only option if you lose it is to reset it.
• Login credentials are always transmitted securely over HTTPS.
• Customer database administrators even have the option to configure the rate limiting and тривалість відновлення для повторних спроб входу.
• Password policies: database administrators have a built-in setting for enforcing a minimum user password length. Other password policies like required character classes are not supported by default because they have been proven counter-productive. See e.g. [Shay et al. 2016]), as well as NIST SP 800-63b.

Staff Access

• Odoo helpdesk staff may sign into your account to access settings related to your support issue. For this they use their own special staff credentials, not your password (which they have no way to know).
• This special staff access improves efficiency and security: they can immediately reproduce the problem you are seeing, you never need to share your password, and we can audit and control staff actions separately!
• Our Helpdesk staff strives to respect your privacy as much as possible, and only access files and settings needed to diagnose and resolve your issue.

System Security

• All Odoo Cloud servers are running hardened Linux distributions with up-to-date security patches.
• Installations are ad-hoc and minimal to limit the number of services that could contain vulnerabilities (no PHP/MySQL stack for example).
• Only a few trusted Odoo engineers have clearance to remotely manage the servers - and access is only possible using an encrypted personal SSH keypair, from a computer with full-disk encryption.

Physical Security

Odoo Cloud servers are hosted in trusted data centers in various regions of the world (e.g. OVH, Google Cloud), and they must all exceed our physical security criterions:

• Restricted perimeter, physically accessed by authorized data center employees only.
• Physical access control with security badges or biometrical security.
• Security cameras monitoring the data center locations 24/7.
• Security personnel on site 24/7.

Credit Card Safety

• We never store credit card information on our own systems.
• Your credit card information is always transmitted securely directly between you and our PCI-Compliant платіжні еквайери (див. список на нашому Політика конфіденційності page).

Data Encryption

• All data communications to client instances are protected with state-of-the-art 256-bit SSL encryption (HTTPS).
• All internal data communications between our servers are also protected with state-of-the-art encryption (SSH).
• Our servers are kept under a strict security watch, and always patched against the latest SSL vulnerabilities, enjoying Grade A SSL ratings at all times.
• All our SSL certificates use robust 2048-bit modulus with full SHA-2 certificates chains.
• All customer data (database content and stored files) is encrypted at rest, both in production and in backups (AES-128 or AES-256)

Network defense

• All data center providers used by Odoo Cloud have very large network capacities, and have designed their infrastructure to withstand the largest Distributed Denial of Service (DDoS) attacks. Their automatic and manual mitigation systems can detect and divert attack traffic at the edge of their multi-continental networks, before it gets the chance to disrupt service availability.
• Firewalls and intrusion prevention systems on Odoo Cloud servers help detect and block threats such as brute-force password attacks.
• Customer database administrators even have the option to configure the rate limiting and cooldown duration for repeated login attempts.

Software Security

Odoo is open source, so the whole codebase is continuously under examination by Odoo users and contributors worldwide. Community bug reports are therefore one important source of feedback regarding security. We encourage developers to audit the code and report security issues.

The Odoo R&D processes have code review steps that include security aspects, for new and contributed pieces of code.

Secure by design

Odoo is designed in a way that prevents introducing most common security vulnerabilities:

• SQL injections are prevented by the use of a higher-level API that does not require manual SQL queries.
• XSS attacks are prevented by the use of a high-level templating system that automatically escapes injected data.
• The framework prevents RPC access to private methods, making it harder to introduce exploitable vulnerabilities.

See also the OWASP Top Vulnerabilities section to see how Odoo is designed from the ground up to prevent such vulnerabilities from appearing.

Independent Security Audits

Odoo is regularly audited by independent companies that are hired by our customers and prospects to perform audits and penetration tests. The Odoo Security Team receives the results and takes appropriate corrective measures whenever it is necessary.

We can't however disclose any of those results, because they are confidential and belong to the commissioners. Please don't ask ;-)

Odoo also has a very active community of independent security researchers, who continuously monitor the source code and work with us to improve and harden the security of Odoo. Our Security Program is described on our Responsible Disclosure сторінці.

OWASP Top Vulnerabilities

Here is where Odoo stands on the top security issue for web applications, as listed by the Open Web Application Security Project (OWASP):

• Недоліки впровадження: Недоліки впровадження, зокрема SQL, є поширеними у веб-додатках. Впровадження відбувається, коли надані користувачем дані надсилаються інтерпретатору як частина команди чи запиту. Ворожі дані зловмисника змушують інтерпретатора виконати ненавмисні команди або змінити дані.

  Odoo relies on an object-relational-mapping (ORM) framework that abstracts query building and prevents SQL injections by default. Developers do not normally craft SQL queries manually, they are generated by the ORM, and parameters are always properly escaped.

• Міжсайтовий скрипт (XSS): Помилки XSS виникають щоразу, коли програма бере надані користувачем дані та надсилає їх у веб-браузер без попередньої перевірки чи кодування цього вмісту. XSS дозволяє зловмисникам виконувати сценарії у браузері жертви, які можуть захоплювати сеанси користувачів, псувати веб-сайти, можливо запроваджувати хробаків тощо.

  The Odoo framework escapes all expressions rendered into views and pages by default, preventing XSS. Developers have to specially mark expressions as "safe" for raw inclusion into rendered pages.

• Підробка міжсайтового запиту (CSRF): Атака CSRF змушує браузер жертви, яка ввійшла в систему, надіслати підроблений HTTP-запит, включаючи файл cookie сеансу жертви та будь-яку іншу автоматично включену інформацію автентифікації, до вразливої веб-програми. Це дозволяє зловмиснику змусити браузер жертви генерувати запити, які вразлива програма вважає законними запитами від жертви.

  The Odoo website engine includes a built-in CSRF protection mechanism. It prevents any HTTP controller to receive a POST request without the corresponding security token. This is the recommended technique for CSRF prevention. This security token is only known and present when the user genuinely accessed the relevant website form, and an attacker cannot forge a request without it.

• Виконання шкідливого файлу: Код, вразливий до віддаленого включення файлів (RFI), дозволяє зловмисникам включати ворожий код і дані, що призводить до руйнівних атак, таких як повна компрометація сервера.

  Odoo does not expose functions to perform remote file inclusion. However it allows privileged users to customize features by adding custom expressions that will be evaluated by the system. These expressions are always evaluated by a sandboxed and sanitized environment that only allows access to permitted functions.

• Незахищене пряме посилання на об’єкт: Пряме посилання на об’єкт виникає, коли розробник надає посилання на внутрішній об’єкт реалізації, наприклад файл, каталог, запис бази даних або ключ, як URL-адресу або параметр форми. Зловмисники можуть маніпулювати цими посиланнями для доступу до інших об’єктів без авторизації.

  Odoo access control is not implemented at the user interface level, so there is no risk in exposing references to internal objects in URLs. Attackers cannot circumvent the access control layer by manipulating those references, because every request still has to go through the data access validation layer.

• Незахищене криптографічне сховище: Веб-додатки рідко використовують криптографічні функції належним чином для захисту даних і облікових даних. Зловмисники використовують слабко захищені дані для крадіжки особистих даних та інших злочинів, таких як шахрайство з кредитними картками.

  Odoo uses industry-standard secure hashing for user passwords (by default PKFDB2 + SHA-512, with key stretching) to protect stored passwords. It is also possible to use external authentication systems such as OAuth 2.0 or LDAP, in order to avoid storing user passwords locally at all.

• Незахищений зв'язок: Програми часто не можуть зашифрувати мережевий трафік, коли це необхідно для захисту конфіденційних даних.

  Odoo Cloud runs on HTTPS by default. For on-premise installations, it is recommended to run Odoo behind a web server implementing the encryption and proxying request to Odoo, for example Apache, Lighttpd or nginx. The Odoo deployment guide includes a Security checklist for safer public deployments.

• Не вдалося обмежити доступ до URL-адреси: Часто програма захищає лише конфіденційні функції, запобігаючи показу посилань або URL-адрес неавторизованим користувачам. Зловмисники можуть використовувати цю слабкість для доступу та виконання несанкціонованих операцій шляхом прямого доступу до цих URL-адрес.

  Odoo access control is not implemented at the user interface level, and the security does not rely on hiding special URLs. Attackers cannot circumvent the access control layer by reusing or manipulating any URL, because every request still has to go through the data access validation layer. In rare cases where a URL provides unauthenticated access to sensitive data, such as special URLs customers use to confirm an order, these URLs are digitally signed with unique tokens and only sent via email to the intended recipient.

Reporting Security Vulnerabilities

If you need to report a security vulnerability, please head over to our responsible disclosure page. Ці звіти обробляються з високим пріоритетом, проблема негайно оцінюється та вирішується командою безпеки Odoo, у співпраці з репортером, а потім у відповідальний спосіб розкривається клієнтам і користувачам Odoo.