Responsible Disclosure Policy

The safety of Instant-ERP systems which whole back end is based on Odoo so it is very important to us (And we use Odoo internally), and we consider security problems with the highest priority. We do our best every day to protect our valued customers from known security threats, and we welcome all reports of security vulnerabilities discovered by our customers.

We are commited to handle vulnerability reports with the greatest speed and care, provided that the following rules are respected.


Reporting an issue

Please share privately the details of your security vulnerability by emailing our Security Team at

Make sure to include as much information as possible, including the detailed steps to reproduce the problem, the versions that are affected, the expected results and actual results, and any other information that might help us react faster and more efficiently.

You may send this report from an anonymous email account, although we promise not to disclose your identity if you do not want us to.

Disclosure Procedure

  1. You privately share the details of the security vulnerability with our Security Team by reporting an issue (see above)
  2. We acknowledge your submission and verify the vulnerability as soon as possible
  3. We work on a correction in collaboration with you
  4. We write a detailed Security Advisory describing the issue, its impacts, possible workarounds and solution, and we ask you to review it
  5. We privately broadcast the Security Advisory and the correction to stakeholders and customers with an Odoo Enterprise Contract
  6. We give stakeholders and customers a reasonable delay to apply the correction, before disclosing it publicly (e.g.: 3 weeks)
  7. We will communicate with our principal , our own Odoo’s partner contact and will wait for their approval for the validating our effort for counter measure proposed
  8. Odoo’s security team will disclose and broadcast the Security Advisory and the correction on Odoo public security channels


We ask you to observe the following rules at all times:

  • Exclusively test vulnerabilities on your own deployments, on the demo db we provided before taking your implementation Online
  • Never attempt to access or modify data that does not belong to you
  • Never attempt to execute denial of service attacks, or to compromise the reliability and integrity of services that do not belong to you
  • Do not use scanners or automated tools to find vulnerabilities, as their effects will violate the previous rules
  • Never attempt non-technical attacks such as social engineering, phishing, or physical attacks against anyone or any system
  • Do not publicly disclose vulnerabilities without our prior consent (see also the Disclosure Procedure above). During the non-disclosure period you are authorized to use/test any correction we’ve provided, as long as no emphasis is put on that correction and it is not published in the form of a security report (i.e. using it on production servers is fine).

In return:

  • We will not initiate legal action against you if you followed the rules
  • We will process your report and respond as quickly as possible
  • We will provide a fix as soon as possible
  • We will keep you updated of the progress and disclosure steps (see also the Disclosure Procedure above)
  • We will work diligently with stakeholders and customers in order to help them restore the safety of their system
  • We will not publically disclose your identity if you do not want to be credited for your discovery

What to report?

Security vulnerabilities are flaws or weaknesses in a system’s design, implementation, or operation and management that could be exploited to violate the system’s security policy.

Here are some examples of vulnerabilities you should report:

  • SQL injection vectors in public API methods
  • XSS vulnerabilities working in supported browsers
  • Broken authentication or session management, allowing unauthorized access
  • Broken sandboxing of customizations, allowing arbitrary code execution or access to system resources

But here are some example of vulnerabilities you should NOT report here, please open regular bug reports instead:

  • XSS vulnerabilities working only in unsupported/deprecated browsers, or requiring relaxed security settings
  • Clickjacking or phishing attacks using social engineering tricks to abuse users, with the system working as intended
  • Open redirectors, considered as vectors to attempt indirect phishing attacks that are also possible directly
  • Scripting/brute-forcing of components working as designed (e.g. password authentication)
  • Disclosure of public information or information that does not carry significant risks
  • Issues in default configuration of access control rules (e.g. ACLs and record rules)
  • If you have any doubt, please ask us first!

Join The Club!

Be the first to learn about
our amazing product

let's save the world together