Security-related rules
Under the hood, SonarQube Cloud uses a variety of source code representations and detection techniques to reliably find all different types of security issues.
The SonarQube quality model is applied to an automated code review and analysis based on 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 uses well-known taint analysis technology on source code which allows, for example, the detection of:
Security-injection rules are supported only by SonarQube Cloud and SonarQube Server. SonarQube for IDE pulls the injection vulnerabilities raised by these products during a project analysis.
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
OWASP Top 10 (versions 2021 and 2017)
OWASP Top 10 security standards covered by Sonar for version 2021
Category
Python
JS/TS
Java
C#
C/C++
PHP
Kotlin
A01:Broken Access Control
A02: Cryptographic Failures
A03: Injection
A04: Insecure Design
A05: Security Misconfiguration
A06: Vulnerable and Outdated Components
A07: Identification and Authentication Failures
A08: Software and Data Integrity Failures
A09: Security Logging and Monitoring Failures
A10: Server-Side Request Forgery
OWASP Mobile Top 10 security standards covered by Sonar for version 2024
Standard
Java
Kotlin
Dart
Swift
M1: Improper Credential Usage
M2: Inadequate Supply Chain Security
M3: Insecure Authentication/Authorization
M4: Insufficient Input/Output Validation
M5: Insecure Communication
M6: Inadequate Privacy Controls
M7: Insufficient Binary Protections
M8: Security Misconfiguration
M9: Insecure Data Storage
M10: Insufficient Cryptography
CWE Top 25 (versions 2024, 2023, 2022, and 2021)
CWE Top 25 security standards covered by Sonar for version 2024
Category
Python
JS/TS
Java
C#
C/C++
PHP
Kotlin
CWE-79 Improper Neutralization of Input During Web Page Generation (‘Cross-site Scripting’)
CWE-787 Out-of-bounds Write
CWE-89 Improper Neutralization of Special Elements used in an SQL Command (‘SQL Injection’)
CWE-352 Cross-Site Request Forgery (CSRF)
CWE-22 Improper Limitation of a Pathname to a Restricted Directory (‘Path Traversal’)
CWE-125 Out-of-bounds Read
CWE-78 Improper Neutralization of Special Elements used in an OS Command (‘OS Command Injection’)
CWE-416 Use After Free
CWE-862 Missing Authorization
CWE-434 Unrestricted Upload of File with Dangerous Type
CWE-94 Improper Control of Generation of Code (‘Code Injection’)
CWE-20 Improper Input Validation
CWE-77 Improper Neutralization of Special Elements used in a Command (‘Command Injection’)
CWE-287 Improper Authentication
CWE-269 Improper Privilege Management
CWE-502 Deserialization of Untrusted Data
CWE-200 Exposure of Sensitive Information to an Unauthorized Actor
CWE-863 Incorrect Authorization
CWE-918 Server-Side Request Forgery (SSRF)
CWE-119 Improper Restriction of Operations within the Bounds of a Memory Buffer
CWE-476 NULL Pointer Dereference
CWE-798 Use of Hard-coded Credentials
CWE-190 Integer Overflow or Wraparound
CWE-400 Uncontrolled Resource Consumption
CWE-306 Missing Authentication for Critical Function
PCI DSS (versions 4.0 and 3.2.1)
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).
Last updated
Was this helpful?