Security bugs are rated by specifying "sec-<rating>" in the "Keyword" field in bugzilla. For example, a bug with a Critical security rating would be marked as "sec-critical".
** Authentication Flaws (which lead to account compromise)
** Session Management Flaws (which lead to account compromise)
|}
;'''sec-high''': Obtain confidential data from other sites the user is visiting or the local machine, or inject data or code into those sites, requiring no more than normal browsing actions. Indefinite DoS of the user's system, requiring OS reinstallation or extensive cleanup. Exploitable web vulnerabilities that can lead to the targeted compromise of a small number of users.
*Failure to use TLS where needed to ensure confidential/security
|}
;'''sec-moderate''': Vulnerabilities which can provide an attacker additional information or positioning that could be used in combination with other vulnerabilities. Disclosure of sensitive information that represents a violation of privacy but by itself does not expose the user or organization to immediate risk. The vulnerability combined with another moderate vulnerability could result in an attack of high or critical severity (aka stepping stone). Indefinite application Denial of Service (DoS) via corruption of state, requiring application re-installation or temporary DoS of the user's system, requiring reboot. The lack of standard defense in depth techniques and security controls.
* Identification of users by profiling browsing behavior.
* Lack of proper input validation (not resulting in XSS or injection)
* Content spoofing (non-html)
|}
;'''sec-other''': Bugs that may not be exploitable security issues but are kept confidential to protect sensitive information. Bugs that contain sensitive information about the bug submitter or another user Bugs that are related to security issues currently unfixed in Mozilla products or other products
* Flaws we need to track that are not in our code base
|}
;'''Mitigating Circumstances''':
If there are mitigating circumstances that severely reduce the effectiveness of the exploit, then the exploit could be reduced by one level of severity. Examples of mitigating circumstances include difficulty in reproducing due to very specific timing or load order requirements, complex or unusual set of actions the user would have to take beyond normal browsing behaviors, or unusual software configuration.
As a rough guide, to be considered for reduction in severity an exploit should execute successfully less than 10% of the time. If measures can be taken to improve the reliability of the exploit to over 10% (by combining it with other existing bugs or techniques), then it should not be considered to be mitigated.