A Plan is a subscription package with pre-installed modules
This depends on your type of business. Most retail shops (supermarkets, restaurants, drycleaners, pharmacy shops etc) will only need the Starter Plan. But your business may need certain modules that are only available in specific plans. For example, a manufacturing company will need the manufacturing module which is only available in the Gold Plan
OdooSME is a monthly service. You can cancel or upgrade at anytime but we currently do not offer downgrade options
Yes. You can use your company name as a sub-domain on our domain name eg yourcompany.odoosome.com. Or you can use your fully qualified domain name eg yourcompany.com
Every free trial is a fully featured OdooSME package depending on the selected modules. By default all free trials are limited to 1-user account. During or after the trial, the user can subscribe from the dashboard, with options to increase the number of users as well as the apps or modules to be installed
Database renewal means the user is renewing the existing plan (same modules and same user) while database upgrade is used to change the current plan by adding users and/or additional modules/apps
Yes. On the pricing page, simply choose your billing cycle (monthly or annual), add subscription details (sub-domain, number of user(s), database username, password) and then click the Buy Now button. We also add back the free trial days to your paid subscription
Security is very important to us, and here is a summary of what we do to guarantee that your data is safe with OdooSME and that we apply the best practices on the hosted services we provide to our customers.
Backups and Disaster recovery
- We keep 14 full backups of each OdooSME instance for up to 3 months: 1/day for 7 days, 1/week for 4 weeks, 1/month for 3 months
- Backups are replicated to at least 3 different machines in different data centers
- You can also download manual backups of your live data at any time using the OdooSME Online control panel
- In case of disaster (never happened so far, but we plan for the worst):
- RPO (Recovery Point Objective) = 24h, i.e. you can lose max 24h of work if the data cannot be recovered and we need to restore the last daily backup
- RTO (Recovery Time Objective) = 6h, i.e. the service will be restored within 6 hours in a different data center if a disaster occurs and a datacenter is completely down.
- 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 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
- OdooSME support staff may sign into your account to access settings related to your support issue (using special staff authorization, not with your password)
- We do our best to respect your privacy as much as possible, we only access files and settings needed to diagnose and resolve your issue
- All OdooSME online 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 OdooSME 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
The OdooSME Online servers are hosted in several data centers worldwide, that must all satisfy with our minimum physical security criterions:
- Physical access to the data center area where OdooSME servers are located is restricted to data center technicians only
- Security cameras are monitoring the data center locations
Credit Card Safety
- When you sign up for a paid OdooSME Online subscription, we do not store your credit card information
- Your credit card information is only transmitted securely between you and our PCI-Compliant payment acquirers: etranzact, 2checkout and Paypal (even for recurring subscriptions)
- All web connections to client instances are protected with state-of-the-art 256-bit SSL encryption
- 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 and the certificates chains are fully using SHA-2 already.
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:
- 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
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
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.