How we rate security issues

In general, a security issue (also known as an exploitable security vulnerability) is a bug that allows a malicious, remote attacker to abuse a victim in some way, such as causing data to be lost or compromised without the explicit consent of the user. In general, a privacy issue in a product such as a browser, is a bug that allows a local, trusted user of the computer to do the same, in a way that would not be expected to be possible by a trusted user who already has been given access to the computer. There are a few exceptions though, such as a bug that allows a remote website to see if you have visited another website, which has privacy implications rather than security implications. Privacy issues in these products are treated very similarly in terms of their importance, but we can only offer researcher credit for security issues.

Note that privacy regulations and the privacy of your data when you are using our services (rather than our products) are covered by our data privacy policies and EU GDPR regulations. Any issues with the handling of that data will generally be treated as security issues, not privacy issues.

Products

The following examples show how we would rate possible security issues relating to our software products which are installed on users‘ computers, such as the Vivaldi Web browser. In all cases, the severity of an exploit is reduced if an attack requires certain common non-default settings to have been selected, or if the user is required to perform significant interactive steps. Severity is reduced further if exploits require very obscure setups or are unlikely to ever affect users.

Critical

• Arbitrary execution of code on a user’s computer, without needing a complicit user.

High

• Arbitrary execution of code on a user’s computer, with a low chance of success, or needing a user to perform several simple actions.
• Cross-site scripting (XSS) against other websites.
• Being able to read or write cookies from other websites.
• Accessing files on a user’s computer (without explicit permission).
• Revealing stored passwords for other websites.
• Revealing other private data from a user’s computer.
• Corrupting the computer’s operating system so that it needs to be reinstalled, with or without associated data loss.

Moderate

• Spoofing in the address field and the connection security dialogs at the same time.
• Making the browser accept false security certificates, or display false connection security information.
• Leaking data between applications or allowing other applications to inject cache files on application-sandboxed platforms.
• Disabling the computer’s operating system so that it needs to be restarted or corrected.

Low

• Spoofing in the address field but not connection security information.
• Security UI that can mislead users.
• Revealing non-sensitive data, such as the dates when other websites were visited. In minor cases, these become privacy issues instead of security issues.
• Disabling the browser so that it cannot restart until it is reinstalled or manually reconfigured.

None (ie. not a security issue)

• Crashes that cannot be used to run arbitrary code, and which do not cause the application to be disabled (Denial of Service).
• Bugs that have been described as exploitable by others, but which do not actually have any security implications.
• Proposed exploits that require a complicit user who will blindly follow multiple instructions via social engineering, or ignore the browser’s security UI.
• UI features that allow a user to intentionally run code to modify a web page, such as bookmarklets or developer tools.
• Out-of-memory (OOM) conditions; Like Chromium, Vivaldi is intentionally not out-of-memory-safe.
• Bugs in Safebrowsing (phishing and malware protection). This is an added protection in addition to the main security UI, and it should not be treated as the main security protection. Safe Browsing bugs normally still require security UI to be bypassed or ignored, in order to abuse users.
• Bugs in private browsing. The private browsing feature is intended to try to hide the most obvious traces of private browsing activity from other trusted users of a computer, once all private windows have been closed. It relates to privacy rather than security, and should not be treated as security protection.

Websites and services

The following examples show how we would rate possible security issues relating to our websites and services.

Critical

• Arbitrary code execution on the server.
• Gaining unauthorised access to the internal network.
• Revealing extensive private data belonging to the service and its users.

High

• Issues that allow gaining access to another user’s account (including missing password hammer protection).
• Revealing substantial private data belonging to a user account.
• SQL injection which allows limited data loss or compromise.
• Reflected cross-site scripting (XSS) which can be used to target a victim.
• Stored cross-site scripting (XSS) which can be used to target a victim.
• Cross-site request forgery (XSRF) which allows data loss or compromise of a user’s account.
• Open redirection to harmful protocols such as javascript: or data:.
• HTTP header injection for harmful headers such as Location:.
• Corruption of service data that requires the service to be reconfigured.

Moderate

• Clickjacking where harmful actions can be done with simple clicks and keypresses.
• Revealing limited private details of a user account, such as an email address or private forum posts.
• XSRF on forms which add new comments or articles, but not to edit or remove them.
• Injection of untrusted content that could be misleading, without XSS.
• HTTPS downgrade attacks, or selecting vulnerable ciphers instead of secure ones.

Low

• Session fixation (cookie reuse).
• XSRF on login forms which subsequently allow limited spying on a user’s browsing activity.
• SMTP open relay.

None (ie. not a security issue)

• Reflected or stored cross-site scripting (XSS) that can only be used to target your own account; If an attacker can only attack themselves rather than a separate victim, then it is not exploitable.
• XSRF on logout forms; This action protects the user’s account from an attacker, and is not harmful.
• XSRF on login forms which do not allow spying on user actions; This only allows an attacker to give a victim access to their own account, which means that the attacker can only attack themselves.
• Exposed local file paths; This is not desirable, and we are grateful to researchers who report it to us, but is not exploitable on its own.
• Exposed server version; Real attacks do not check server make or version, they just try all attacks and see if one works.
• Open directory listings; We are a software company, and this is how we intentionally offer content for downloads. The real issue would be relying on security by obscurity when hiding sensitive content in a directory.
• FTP servers which allow downloads without a login; We are a software company, and this is how we intentionally offer content for download.
• Clickjacking where there are no harmful actions can be done with simple clicks and keypresses (eg. login forms); Clickjacking relies on being able to perform harmful actions with simple clicks and keypresses.
• Open redirection to harmless protocols (phishing); These do not make phishing any worse, since it will always be possible via other means, and phishing attacks rely on users not reading URLs anyway.
• Slightly outdated third party server software versions with recently announced known issues; This is not an issue in our own software, and third party software is updated on a schedule determined by the system administrators.
• Newly discovered issues in third party software used by the service; This needs to be reported to the third party vendor directly, rather than to us.
• Issues in third party modules which are installed but not enabled.
• Issues in third party administration tools which are not publicly accessible.
• Email spoofing not prevented with SPF, DKIM or DMARC.
• Temporary denial of service against the website.

Some issues, such as XML entity expansion, will vary in their severity depending on the impact of the specific issue. Some may, for example, only result in a denial of service, while others may reveal confidential data. Badly outdated third party server software with known security issues needs to be updated, and we are grateful to be told about it, but note that it is not normally eligible for researcher credits on our site, as it is up to the third party to offer credit for issues in their software. However, if we are misusing that software in a way that causes issues to appear, these will be considered eligible for credits in accordance with the impacts listed above.