Security aspects of Odoo

We know there are various mechanisms to keep a cloud-based business application secure. Use of client side certificates, checking a valid web browser certificate installed or not , allow service to be accessed from pre-defined locations, use of VPN's to access internal applications from known sites, allow to access URL's from certain locations, make use of monitoring application reports etc are some of them we do traditionally. But these won't mitigate many issues. Also the above solutions won't address the software design flaw.

Let's see how Odoo handles 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.

The inherent "Data Model" mechanisms of the Model-View-Controller (MVC) method used within Odoo lessens the chances of a problem, and also reduces the time to detect and resolve. The "Data Model" is a principle, not actual software. The methodology can be applied in many ways, revolving around a key principle, that is to not directly access the database, but use a "Data Model" interface which abstracts the actual data store from the application. This Model can join different data sources together - even remote data, introduce security, constraints, auditing and many other features. This does have an impact on performance, but with a well designed application and database schema, performance should be of no concern on modern computers even with large data sets accessed by hundreds of concurrent users.

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: 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): 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): 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: 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: 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: 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.
• Failure to Restrict URL Access.
• 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.

Apart from these , we can also ensure the following during production deployment.

• Set private ssh key for your Odoo server.
• Start your Odoo in SSL mode.
• Install Nginx in your Ubuntu Server.
• Stop access of all unnecessary ports from firewall of your Ubuntu Server.
• Set proper data access rights & access rules into your Odoo instance.
• Set proper authentication method for your PostgreSQL database user.
• Set tricky password for PostgreSQL user.
• Apply encryption on Database and Odoo user passwords.
• Set Tricky password for Super Admin.
• Request all your ERP users to set difficult password.
• Give FTP access for your ERP users and don't allow them to create files out of their directory on your Ubuntu Server.
• Set proper access rights on your custom addons and default Odoo addons via chmod and chown commands.
• Have a look on /var/log/postgresql/postgresql-9.1-main.log file for malware attack on your database.
• Manage your Odoo log file properly.
• Transfer database & custom addons backup to remote place at frequent amount of time.
• Change and set tricky password for detault postgres user in your database server.
• Stop xmlrpc if you don't want your ERP to connect from 3rd party systems. ( set xmlrpc=False in your config file ).
• Remove "Manage Database" link from home page of your live Odoo instance.
• Ignore installation of Odoo where multiple other websites are hosted.
• We highly recommend to ignore creation of any kind of demo database in Live Odoo instance. 
• Ignore to host your Odoo in Web hosting servers, always host Odoo in trusted VPS sites. ( Amazon, Raskspace, DigitalOcen, Myhosting etc..).
• Monitor Incoming and outgoing TCP/IP traffics in your Ubuntu Server. Few of our customers for whom we have implemented Odoo for more then 150+ users, they hired their own server administrator to monitor incoming and outgoing TCP/IP traffics. ( Visit this link ).
• Never give full access of your server to your Odoo service providers, always give them folder access of their own custom addons with their separate user. ( It's advisable to not share root user password to anyone. ).
• If customer can afford healthy cost, we always suggest them to set up their own in-house hosting server instead of VPS.