Last updated 24 May 2018
Our website and general business computer system, Odoo Cloud, are integrated and provided by Odoo.com. This policy sets out how we manage the security of our data and is held under review and will be updated from time to time in line with general technological changes and advances.
Backups / Disaster Recovery
Odoo keeps 14 full system backups 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 different continents
Hardware failover: for services hosted on bare metal, where hardware failure is possible, Odoo implement local hot standby replication, with monitoring and a manual failover procedure that takes less than 5 minutes
Disaster recovery: in case of complete disaster, with a data center entirely down for an extended period, preventing the failover to our local hot-standby (never happened so far, this is the worst-case plan), Odoo have the following objectives:
RPO (Recovery Point Objective) = 24h. This means Lampfix can lose max 24h of work if the data cannot be recovered and we need to restore our latest daily backup
RTO (Recovery Time Objective) = 24h. 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: Odoo actively monitor our daily backups, and they are replicated in multiples locations on different continents. Odoo have automated provisioning to deploy Odoo's 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).
Odoo 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.
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
- 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 retrieve it for you, the only option if you lose it is to reset it
- Login credentials are always transmitted securely over HTTPS
Odoo Staff Access
- Odoo helpdesk staff may sign into Lampfix's database to access settings related to a support issue. For this they use their own special staff credentials, not Lampfix's password (which they have no way to know).
- This special staff access improves efficiency and security: they can immediately reproduce issues with no need to share a password, and Odoo can audit and control Odoo staff actions separately.
- 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 SSH key pairs (password authentication disallowed)
- Firewalls and intrusion counter-measures help prevent unauthorized access
- Automatic Distributed Denial of Service (DDoS) mitigation is implemented in EU and US data centers, and coming soon in Asia
Odoo 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
When you make a payment by phone or on our website, we do not store your credit card information
Your credit card information is only transmitted securely between you and our PCI-Compliant payment acquirers (even for recurring subscriptions). We currently use PayPal and Sagepay.
All web connections to client instances are protected with state-of-the-art 256-bit SSL encryption
Odoo 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
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 their 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.
Odoo cannot however disclose any of those results, because they are confidential and belong to the commissioners.
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. Odoo's Security Program is described on its Responsible Disclosure page.
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):
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.
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.
Cross Site Request Forgery (CSRF): A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request, including the victim’s session cookie and any other automatically included authentication information, to a vulnerable web application. This allows the attacker to force the victim’s browser to generate requests the vulnerable application thinks are legitimate requests from the victim.
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.
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 Cloud runs on HTTPS by default.
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.
Reporting Security Vulnerabilities
If you need to report a security vulnerability, please contact our Security Office using contact details on our contact us page. These reports are treated with high priority, the problem is immediately assessed and solved by the Odoo security team, in collaboration with the reporter, and then disclosed in a responsible manner to the affected parties.