Responsible Disclosure Policy

• XSS vulnerabilities working only in unsupported/deprecated browsers, or requiring relaxed security settings
• Self-XSS attacks requiring the user to actively copy/paste malicious code into their own browser window
  
• "XSS attacks" by admins, e.g. via file uploads (SVG, HTML, JS, ...) or script injection. Administrators are webmasters, security restrictions don't apply to them, this is a feature.
• Rate-limiting / Brute-forcing / Scripting of components working as designed (e.g. password authentication, password reset, etc.)
• User enumeration (ability to verify that a username exists). Does not carry much risk, and can't be prevented without deteriorating the user experience.
• File path disclosures, which do not carry significant risk and do not enable attacks that would be otherwise impossible
• Clickjacking or phishing attacks using social engineering tricks to abuse users, with the system working as intended
• Tabnapping or other phishing attacks conducted by navigating other browser tabs
• Logout CSRF (no plausible attack unless combined with Login CSRF + not preventable e.g. via cookie tossing or cookie jar overflow)
• Open redirectors, which are simply one vector for phishing among many others ( see our detailed explanation)
• Reflected File Downloads, another attack technique that requires social engineering and is not very practical
• Referer leak (including sensitive tokens) via social media links or ads/analytics requests - very unlikely to be clicked, or to be exploited within validity period by those mainstream companies! 
• More generally, attacks relying on physical or social engineering techniques will usually be rejected
• Non-permanent Denial of Service (DoS) and distributed DoS (DDoS) that maintain resource exhaustion (cpu/network/memory/...) via a sustained stream of requests/packets
• Password policies (length, format, character classes, etc.)
• Missing or partial verification of email addresses, or ways to circumvent it
  
• Disclosure of public information or information that does not carry significant risks (directory listing on our downloads archive is a required feature! ;-))
• Spam-fighting policies and systems such as DKIM, SPF or DMARC
• Absence of HTTP Strict Transport Security (HSTS) headers, HSTS preloading, and HSTS policies 
• Weak ciphers or SSL deployments details. Our benchmark is an A grade on SSLLab's test yet a maximal compatibility with user browsers. We are currently phasing out TLS 1.0 on www.odoo.com, already done for our customer hosting services
• SSRF attacks, unless they allow access to special protocol handlers (e.g. file://), or can be used in a working scenario to bypass access control on the Odoo Cloud Hosting (cfr deployment documentation)
• Issues in default configuration of access control rules (e.g. ACLs and record rules) - please open regular bug reports instead
• Attack scenarios that include a prior takeover of the user account or an email account of the user - please open regular bug reports instead

If you have any doubt, please ask us first!