Security-related rules

The SonarQube quality model has the following types of rules: 

• Reliability (Bug)
• Maintainability (Code Smell)
• Security (Vulnerability) 
• Security Hotspot

Security-related rules include Security rules and Security Hotspot rules. They are divided into two types: security-injection and security-configuration rules.

Security-injection rules

Security-injection rules are used to detect injection vulnerabilities. An injection vulnerability (also known as injection flaw or taint vulnerability) occurs when the inputs handled by your application are controlled by a user (potentially an attacker) and not validated or sanitized. When this occurs, the flow from sources (user-controlled inputs) to sinks (sensitive functions) will be presented. Common types include SQL Injection, Deserialization, and Command Injection vulnerabilities. 

To show the flow of tainted issues, SonarQube Server uses well-known taint analysis technology on source code which allows, for example, the detection of:

• CWE-89: SQL Injection
• CWE-79: Cross-site Scripting
• CWE-94: Code Injection

Security-configuration rules

The security-configuration rules are used to raise a security issue when:

• A sensitive function is called with a wrong parameter (invalid cryptographic algorithm or TLS version).
• A check (for example, a check_permissions() kind of function) is not done or is not in the correct order.
  This problem is likely to appear often when the program is executed.

Examples:

• CWE-1004: Sensitive Cookie Without 'HttpOnly' Flag
• CWE-297: Improper Validation of Certificate with Host Mismatch
• CWE-327: Use of a Broken or Risky Cryptographic Algorithm

Differences between security issues (vulnerabilities) and hotspots

Security hotspots have been introduced for security protections that have no direct impact on the overall application's security. With hotspots, we want to help developers understand information security risks, threats, impacts, root causes of security issues, and the choice of relevant software protections. In short, we really want to educate developers and help them develop secure, ethical, and privacy-friendly applications.

For more information about hotspots and vulnerabilities, see the Security hotspots page.

Security standards covered

Our security rules are classified according to well-established security standards such as:

• CWE: SonarQube Community Build is a CWE-compatible product since 2015.
• OWASP Top 10
• SANS Top 25 - outdated

You can search for a rule on rules.sonarsource.com. The standards to which a rule relates will be listed in the See section at the bottom of the rule description. Some detailed examples of Java vulnerabilities are listed here:

• Java-vulnerability-issue-type: all vulnerability rules for Java language.
• Java-hotspots-issue-type: all security-hotspot rules for Java language.
• Java-tag-injection: all security-injection rules for Java language (not supported in SonarQube Community Build).