Security in Odoo
Aside from manually managing access using custom code, Odoo provides two main data-driven mechanisms to manage or restrict access to data.
Both mechanisms are linked to specific users through groups: a user belongs to any number of groups, and security mechanisms are associated to groups, thus applying security mechanisms to users.
serves as user-readable identification for the group (spells out the role / purpose of the group)
The module category, serves to associate groups with an Odoo App (~a set of related business models) and convert them into an exclusive selection in the user form.
Other groups to set on the user alongside this one. This is a convenience pseudo-inheritance relationship: it’s possible to explicitly remove implied groups from a user without removing the implier.
Additional notes on the group e.g.
Grants access to an entire model for a given set of operations. If no access rights matches an operation on a model for a user (through their group), the user doesn’t have access.
Access rights are additive, a user’s accesses are the union of the accesses they get through all their groups e.g. given a user who is part of group A granting read and create access and a group B granting update access, the user will have all three of create, read, and update.
The purpose or role of the group.
The model whose access the ACL controls.
perm_methodattributes grant the corresponding CRUD access when set, they are all unset by default.
Record rules are conditions which must be satisfied in order for an operation to be allowed. Record rules are evaluated record-by-record, following access rights.
Access rules are default-allow: if access rights grant access and no rule applies to the operation and model for the user, the access is granted.
The description of the rule.
The model to which the rule applies.
res.groupsto which access is granted (or not). Multiple groups can be specified. If no group is specified, the rule is global which is treated differently than “group” rules (see below).
Computed on the basis of
groups, provides easy access to the global status (or not) of the rule.
A predicate specified as a domain, the rule allows the selected operations if the domain matches the record, and forbids it otherwise.
The domain is a python expression which can use the following variables:
The current user, as a singleton recordset.
The current user’s currently selected company as a single company id (not a recordset).
All the companies to which the current user has access as a list of company ids (not a recordset), see Security rules for more details.
perm_methodhave completely different semantics than for
ir.model.access: for rules, they specify which operation the rules applies for. If an operation is not selected, then the rule is not checked for it, as if the rule did not exist.
All operations are selected by default.
Global rules versus group rules
There is a large difference between global and group rules in how they compose and combine:
Global rules intersect, if two global rules apply then both must be satisfied for the access to be granted, this means adding global rules always restricts access further.
Group rules unify, if two group rules apply then either can be satisfied for the access to be granted. This means adding group rules can expand access, but not beyond the bounds defined by global rules.
The global and group rulesets intersect, which means the first group rule being added to a given global ruleset will restrict access.
If the current user is not in one of the listed groups, he will not have access to the field:
restricted fields are automatically removed from requested views
restricted fields are removed from
attempts to (explicitly) read from or write to restricted fields results in an access error
As a developer, it is important to understand the security mechanisms and avoid common mistakes leading to insecure code.
Unsafe Public Methods
Any public method can be executed via a RPC call with the chosen parameters. The methods starting with a
_ are not callable from an action button or external API.
On public methods, the record on which a method is executed and the parameters can not be trusted, ACL being only verified during CRUD operations.
Making a method private is obviously not enough and care must be taken to use it properly.
Bypassing the ORM
You should never use the database cursor directly when the ORM can do the same thing! By doing so you are bypassing all the ORM features, possibly the automated behaviours like translations, invalidation of fields,
active, access rights and so on.
And chances are that you are also making the code harder to read and probably less secure.
Care must be taken not to introduce SQL injections vulnerabilities when using manual SQL queries. The vulnerability is present when user input is either incorrectly filtered or badly quoted, allowing an attacker to introduce undesirable clauses to a SQL query (such as circumventing filters or executing
The best way to be safe is to never, NEVER use Python string concatenation (+) or string parameters interpolation (%) to pass variables to a SQL query string.
The second reason, which is almost as important, is that it is the job of the database abstraction layer (psycopg2) to decide how to format query parameters, not your job! For example psycopg2 knows that when you pass a list of values it needs to format them as a comma-separated list, enclosed in parentheses !
This is very important, so please be careful also when refactoring, and most importantly do not copy these patterns!
Here is a memorable example to help you remember what the issue is about (but do not copy the code there). Before continuing, please be sure to read the online documentation of pyscopg2 to learn of to use it properly:
Unescaped field content
t-raw to display rich-text content. This should be avoided as a frequent XSS vector.
It is very hard to control the integrity of the data from the computation until the final integration in the browser DOM. A
t-raw that is correctly escaped at the time of introduction may no longer be safe at the next bugfix or refactoring.
The above code may feel safe as the message content is controlled but is a bad practice that may lead to unexpected security vulnerabilities once this code evolves in the future.
While formatting the template differently would prevent such vulnerabilities.
Escaping vs Sanitizing
Escaping converts TEXT to CODE. It is absolutely mandatory to do it every time you mix DATA/TEXT with CODE (e.g. generating HTML or python code to be evaluated inside a
safe_eval), because CODE always requires TEXT to be encoded. It is critical for security, but it’s also a question of correctness. Even when there is no security risk (because the text is 100% guarantee to be safe or trusted), it is still required (e.g. to avoid breaking the layout in generated HTML).
Escaping will never break any feature, as long as the developer identifies which variable contains TEXT and which contains CODE.
Sanitizing converts CODE to SAFER CODE (but not necessary safe code). It does not work on TEXT. Sanitizing is only necessary when CODE is untrusted, because it comes in full or in part from some user-provided data. If the user-provided data is in the form of TEXT (e.g. the content from a form filled by a user), and if that data was correctly escaped before putting it in CODE, then sanitizing is useless (but can still be done). If however, the user-provided data was not escaped, then sanitizing will not work as expected.
Sanitizing can break features, depending on whether the CODE is expected to contain patterns that are not safe. That’s why
tools.html_sanitize() have options to fine-tune the level of sanitization for styles, etc. Those options have to be carefully considered depending on where the data comes from, and the desired features. The sanitization safety is balanced against sanitization breakages: the safer the sanitisation the more likely it is to break things.
Some may want to
eval to parse user provided content. Using
eval should be avoided at all cost. A safer, sandboxed, method
safe_eval can be used instead but still gives tremendous capabilities to the user running it and must be reserved for trusted privileged users only as it breaks the barrier between code and data.
Parsing content does not need
int, float, etc.
int, float, etc.
object, list, etc.
Accessing object attributes
If the values of a record needs to be retrieved or modified dynamically, one may want to use the
This code is however not safe as it allows to access any property of the record, including private attributes or methods.
__getitem__ of a recordset has been defined and accessing a dynamic field value can be easily achieved safely:
The above method is obviously still too optimistic and additional verifications on the record id and field value must be done.