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 a security check for all new and contributed pieces of code.

Many customers have conducted independent code audits and performed penetration tests, and all the findings have been taken into consideration. The results can only be disclosed by the respective customers, though.

Odoo is designed in a way that prevents the most common types of security issues:

• • 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 all data being rendered
  • The framework prevents RPC access to private methods, making it harder to introduce exploitable vulnerabilities

OWASP Top Security Issues

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

• • Cross Site Scripting (XSS): XSS flaws occur whenever an application takes user supplied 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 hijack user sessions, deface web sites, possibly introduce worms, etc.
  • 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.
  • Injection Flaws: Injection flaws, particularly 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 changing data.
  • 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.
  • Malicious File Execution: Code vulnerable to remote file inclusion (RFI) allows attackers to include hostile code and data, resulting in devastating attacks, such as total 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.
  • Insecure 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 those references to access other objects without authorization.
  • 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 manipulation those references, because every 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 weakly protected data to conduct identity theft and other crimes, such as credit card fraud.
  • 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.
  • Insecure Communications: Applications frequently fail to encrypt network traffic when it is necessary to protect sensitive communications.
  • Odoo Online runs on HTTPS by default. For on-premise installations, it is recommend to run Odoo behind a web server implementing the encryption and proxying request to Odoo, for example Apache, Lighttpd or nginx.
  • Failure to Restrict URL Access: Frequently an application only protects sensitive functionality by preventing the display of links or URLs to unauthorized users. Attackers can use this weakness to access and perform unauthorized operations by accessing those URLs directly
    • 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 customer use to confirm an order, these URLs are digitally signed with unique tokens and only sent via email to the intended recipient.