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 is a lively world where new types of attacks and vulnerabilities appear very often, so we welcome any suggestions for new security rules. You can read the Adding coding rules page to see how to develop a new rule or propose a new one on our Community forum.
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:
- Security-injection rules are supported only by SonarQube Server and Cloud. SonarQube for IDE pulls the injection vulnerabilities raised by these products during a project analysis.
- With SonarQube Server's Security engine custom configuration, it's possible to extend the taint analysis of security-injection rules by configuring new sources, sanitizers, validators and sinks within the homemade frameworks that you use.
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:
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:
- 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 |
| 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 | | | | | |
- CWE Top 25 (versions 2023, 2022, and 2021)
CWE Top 25 security standards covered by Sonar for version 2023
| Category | Python | JS/TS | Java | C# | C/C++ | PHP |
| CWE-787: Out-of-bounds Write | | |||||
| CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') | | | | | | |
| CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') | | | | | | |
| CWE-416: Use After Free | | |||||
| CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') | | | | | | |
| CWE-20: Improper Input Validation | | | | | | |
| CWE-125: Out-of-bounds Read | | |||||
| CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') | | | | | | |
| CWE-352: Cross-Site Request Forgery (CSRF) | | | | | | |
| CWE-434: Unrestricted Upload of File with Dangerous Type | | |||||
| CWE-862: Missing Authorization | ||||||
| CWE-476: NULL Pointer Dereference | | | | | | |
| CWE-287: Improper Authentication | | |||||
| CWE-190: Integer Overflow or Wraparound | | | | |||
| CWE-502: Deserialization of Untrusted Data | | | | | ||
| CWE-77: Improper Neutralization of Special Elements used in a Command ('Command Injection') | | | | | | |
| CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer | | |||||
| CWE-798: Use of Hard-coded Credentials | | | | | | |
| CWE-918: Server-Side Request Forgery (SSRF) | | | | | | |
| CWE-306: Missing Authentication for Critical Function | ||||||
| CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') | ||||||
| CWE-269: Improper Privilege Management | | | ||||
| CWE-94: Improper Control of Generation of Code ('Code Injection') | | | | | | |
| CWE-863: Incorrect Authorization | ||||||
| CWE-276: Incorrect Default Permissions |
- OWASP ASVS 4.0 Level 1, 2, 3
- PCI DSS (versions 4.0 and 3.2.1)
- CASA
- STIG
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).
Was this page helpful?
© 2008-2025 SonarSource SA. All rights reserved. SONAR, SONARSOURCE, SONARQUBE, and CLEAN AS YOU CODE are trademarks of SonarSource SA.
