Security

Backups / Disaster RecoveryDatabase SecurityPassword SecurityTeam AccessSystem SecurityPhysical SecurityCredit Card SecurityData encryptionDefense networkSoftware SecuritySecurity by DesignIndependent security auditsOWASP Major VulnerabilitiesReporting Security Vulnerabilities

Backups / Disaster Recovery

  • We keep 14 full backups of each Odoo database for at least 3 months: 1 per day for 7 days, 1 per week for 4 weeks, 1 per month for 3 months.
  • Backups are replicated across at least 3 different data centers, on at least 2 different continents.
  • The actual locations of our data centers are specified in our Privacy Policy .
  • You can also download manual backups of your data at any time using the control panel.
  • You can contact our Help Center to recover any of these backups to your active database (or others)
  • Hardware Failure: For bare metal services where hardware failure is possible, we implement hot standby replication with monitoring and manual failure handling that takes less than five minutes.
  • Disaster Recovery: In the event of a total disaster, with a data center completely offline for an extended period, to avoid the failure of our local hot-standby (it has never happened before, and is the worst-case scenario), we have the following goals:
    • RPO (Recovery Point Objective) = 24h. This means that you can lose a maximum of 24 hours of work if the data cannot be recovered and we need to restore your last daily backup.
    • RTO (Recovery Time Objective) = 24h for paid subscriptions, 48h for free trials, educational offerings, freemium users, etc. This is the time to restore service to a different data center if a disaster occurs and one data center goes completely down.
    • How it’s done: We actively monitor our daily backups and they are replicated across multiple locations on different continents. We have automated provisioning in place to deploy our services to a new hosting location. Restoring data from our previous day’s backups can be done within hours (for the largest clusters), with priority given to paid subscriptions.
      We routinely use both daily backups and provisioning scripts for day-to-day operations, so both parts of the disaster recovery process are tested at all times.

Database Security

  • Customer data is stored in a dedicated database - no data sharing between customers.
  • Data access control rules implement complete isolation between customer databases running on the same cluster, making it impossible for one database to access another.

Password Security

  • Customer passwords are protected with industry-standard PBKDF2+SHA512 encryption ("salted" + "stretched" for thousands of rounds).
  • Odoo staff do not have access to your password and cannot recover it, 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 limit  and cooldown duration for repeated login attempts.
  • Password policies: Database administrators have a pre-configured setting to enforce a minimum user password length. Other password policies such as requiring character classes are not supported by default because they have proven to be counterproductive. See for example, [ Shay et al. 2016 ]), as well as NIST SP 800-63b .

Team Access

  • The Odoo Help Center team can log into your account to access settings related to your support issue. They do this using their own special personal credentials, not your password (which they have no way of knowing).
  • This special team access improves efficiency and security: they can immediately reproduce the issue you're seeing, you never have to share your password, and we can audit and control team actions separately!
  • Our Help Center team strives to respect your privacy as much as possible and only accesses files and settings necessary 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 may contain vulnerabilities (no PHP/MySQL stack, for example).
  • Only a few trusted Odoo engineers are authorized to remotely manage the servers - and access is only possible using a pair of encrypted personal SSH keys, from a computer with full disk encryption.

Physical Security

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

  • Restricted perimeter, physically accessed only by authorized data center employees.
  • Physical access control with security badges or biometric security.
  • Security cameras monitoring data center locations 24/7.
  • Security personnel on site 24 hours a day, 7 days a week.

Credit Card Security

  • We never store credit card information on our systems.
  • Your credit card information is always transmitted securely directly between you and our  PCI compliant  payment acquirer (see list on Privacy Policy page).

Data encryption

Customer data is always transferred and stored in encrypted form (encryption in transit and at rest ).

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

Defense network

  • 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 has a chance to disrupt service availability.
  • Firewalls and intrusion prevention systems on Odoo Cloud servers help detect and block threats such as direct-execution password attacks.
  • Customer database administrators even have the option to configure rate limiting and cooldown duration for repeated login attempts.

Software Security

Odoo is open source, so the entire codebase is under constant review by Odoo users and contributors worldwide. Community bug reports are therefore an important source of security feedback. We encourage developers to audit the code and report security issues.

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


Security by Design

Odoo is designed to avoid the most common security vulnerabilities:

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

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

Independent security audits

Odoo is regularly audited by independent companies that are hired by our clients and potential clients to perform audits and penetration tests. The Odoo security team receives the results and takes appropriate corrective action whenever necessary.

However, we cannot disclose any of these results, because they are confidential and belong to the commissioners. Please do not ask ;-)

Odoo also has a very active community of independent security analysts, who continuously monitor the source code and work with us to improve and strengthen Odoo's security. Our security program is described on our Responsible Disclosure page.

OWASP Major Vulnerabilities

Here is Odoo's stance on the top security issues for web applications as listed by the Open Web Application Security Project (OWASP):

  • Injection flaws: Injection flaws, especially SQL injection, are common in web applications. Injection occurs when user-supplied data is sent to an interpreter as part of a command or query. The attacker's hostile data tricks the interpreter into executing unintended commands or altering data.
    Odoo relies on an object-relational mapping (ORM) framework that abstracts query creation and prevents SQL injections by default. Typically, developers do not create SQL queries manually, they are generated by the ORM and parameters are always properly escaped.
  • Cross Site Scripting (XSS): XSS flaws occur whenever an application collects user-provided data and sends it to a web browser without first validating or encoding that content. XSS allows attackers to execute scripts in the victim's browser, which can lead to hijacking user sessions, corrupting websites, introducing viruses, etc.
    By default, the Odoo framework escapes all rendered expressions in views and pages, preventing XSS. Developers need to specially mark expressions as "safe" for raw inclusion in rendered pages.
  • Cross-Site Request Forgery (SIF): A SIF attack forces a logged-in victim's browser to send a forged HTTP request, including the victim's session cookie and other automatically included authentication information, to a vulnerable web application. This allows the attacker to force the victim's browser to generate requests that the vulnerable application considers to be legitimate requests from the victim.
    The Odoo website engine includes a built-in CSRF protection mechanism. It prevents any HTTP controller from receiving 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 has actually accessed the relevant website form, and an attacker cannot forge a request without it.
  • Malicious file execution: Code vulnerable to remote file inclusion (RFI) allows attackers to include hostile code and data, resulting in devastating attacks such as complete server compromise.
    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.
  • Unsafe Direct Object Reference: A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, database record, or key, as a URL or form parameter. Attackers can manipulate these references to access other objects without authorization.
    Odoo's 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 bypass the access control layer by manipulating these references, because each request still has to go through the data access validation layer.
  • Insecure cryptographic storage: Web applications rarely use cryptographic functions properly to protect data and credentials. Attackers use poorly protected data for identity theft and other crimes such as credit card fraud.
    Odoo uses industry-standard secure hashing for user passwords (by default PBKDF2 + SHA-512, with key stretching) to protect stored passwords. You can also use external authentication systems such as OAuth 2.0 or LDAP to avoid storing user passwords locally.
  • Unsecure communications: Applications often do not encrypt network traffic when it is necessary to protect sensitive communications.
    Odoo Cloud runs over HTTPS by default. For on-premises installations, it is recommended to run Odoo behind a web server that implements encryption and request proxying for Odoo, e.g. Apache, Lighttpd or nginx. The Odoo implementation guide includes a Security Checklist for secure public deployments.
  • Failure to Restrict URL Access: Often, applications only protect sensitive functionality by preventing links or URLs from being presented to unauthorized users. Cyber ​​attackers can use this weakness to access and perform unauthorized operations by accessing these URLs directly.
    Odoo's access control is not implemented at the user interface level, and security does not rely on hiding special URLs. Attackers cannot bypass the access control layer by reusing or manipulating any URL, because each 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 that customers use to confirm an order, these URLs are digitally signed with unique tokens and only emailed to the intended recipient.

Reporting Security Vulnerabilities

If you need to report a security vulnerability, please direct yourself to our responsible disclosure page . Reports are treated with high priority. The issue is immediately assessed and resolved by the Odoo security team in collaboration with the reporter, and then responsibly disclosed to Odoo customers and users.