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:

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

For each injection vulnerability, SonarQube Cloud displays up to 20 flows. For more information on execution flows, see Execution flow.

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

Note: To simplify the classification of findings, we are gradually transitioning security hotspots to vulnerabilities. As a result, rules that previously raised security hotspots will start raising vulnerabilities (type) or security issues (software quality).

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 hotspot rules page.

Security standards covered

OWASP Top 10 (versions 2025, 2021, 2017)

OWASP Top 10 security standards covered by Sonar for version 2025

Category

Python

JS/TS

Java

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

EU Cyber Resilience Act

EU Cyber Resilience Act security standards covered by Sonar security features

Requirement

Security

Dependency Risks

Part I - Cybersecurity requirements relating to the properties of products with digital elements

(partial)

1.1 Risk-Based Security Standards for Digital Products

1.2 Security Obligations Derived from Risk Assessments

1.2.a be made available on the market without known exploitable vulnerabilities

1.2.b be made available on the market with a secure by default configuration, unless otherwise agreed between manufacturer and business user in relation to a tailor-made product with digital elements, including the possibility to reset the product to its original state

1.2.c ensure that vulnerabilities can be addressed through security updates, including, where applicable, through automatic security updates that are installed within an appropriate timeframe enabled as a default setting, with a clear and easy-to-use opt-out mechanism, through the notification of available updates to users, and the option to temporarily postpone them

1.2.d ensure protection from unauthorised access by appropriate control mechanisms, including but not limited to authentication, identity or access management systems, and report on possible unauthorised access

1.2.e protect the confidentiality of stored, transmitted or otherwise processed data, personal or other, such as by encrypting relevant data at rest or in transit by state of the art mechanisms, and by using other technical means

1.2.f protect the integrity of stored, transmitted or otherwise processed data, personal or other, commands, programs and configuration against any manipulation or modification not authorised by the user, and report on corruptions

1.2.g process only data, personal or other, that are adequate, relevant and limited to what is necessary in relation to the intended purpose of the product with digital elements (data minimisation)

1.2.h protect the availability of essential and basic functions, also after an incident, including through resilience and mitigation measures against denial-of-service attacks

1.2.i minimise the negative impact by the products themselves or connected devices on the availability of services provided by other devices or networks

1.2.j be designed, developed and produced to limit attack surfaces, including external interfaces

1.2.k be designed, developed and produced to reduce the impact of an incident using appropriate exploitation mitigation mechanisms and techniques

1.2.l provide security related information by recording and monitoring relevant internal activity, including the access to or modification of data, services or functions, with an opt-out mechanism for the user

1.2.m provide the possibility for users to securely and easily remove on a permanent basis all data and settings and, where such data can be transferred to other products or systems, ensure that this is done in a secure manner

Part II - Vulnerability handling requirements

2.1 identify and document vulnerabilities and components contained in products with digital elements, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the products

2.2 in relation to the risks posed to products with digital elements, address and remediate vulnerabilities without delay, including by providing security updates; where technically feasible, new security updates shall be provided separately from functionality updates

2.3 apply effective and regular tests and reviews of the security of the product with digital elements

2.4 once a security update has been made available, share and publicly disclose information about fixed vulnerabilities, including a description of the vulnerabilities, information allowing users to identify the product with digital elements affected, the impacts of the vulnerabilities, their severity and clear and accessible information helping users to remediate the vulnerabilities; in duly justified cases, where manufacturers consider the security risks of publication to outweigh the security benefits, they may delay making public information regarding a fixed vulnerability until after users have been given the possibility to apply the relevant patch

2.5 put in place and enforce a policy on coordinated vulnerability disclosure

2.6 take measures to facilitate the sharing of information about potential vulnerabilities in their product with digital elements as well as in third-party components contained in that product, including by providing a contact address for the reporting of the vulnerabilities discovered in the product with digital elements

2.7 provide for mechanisms to securely distribute updates for products with digital elements to ensure that vulnerabilities are fixed or mitigated in a timely manner and, where applicable for security updates, in an automatic manner

2.8 ensure that, where security updates are available to address identified security issues, they are disseminated without delay and, unless otherwise agreed between a manufacturer and a business user in relation to a tailor-made product with digital elements, free of charge, accompanied by advisory messages providing users with the relevant information, including on potential action to be taken

CASA
OWASP ASVS (version 4.0 level 1, 2, 3)
PCI DSS (versions 4.0 and 3.2.1)
STIG ASD (version 6 and 5)

PreviousSonarQube rules

NextSecurity hotspot rules

Last updated 1 month ago

Was this helpful?

Security-injection rules

Security-configuration rules

Differences between security issues (vulnerabilities) and hotspots

Security standards covered

Related pages