This version of the SonarQube documentation is no longer maintained. It relates to a version of SonarQube that is not active.

See latest version
Start Free
10.7 | User guide | Understanding rules | Security-related rules

Security-related rules

On this page

The SonarQube quality model has four different types of rules: reliability (bug), maintainability (code smell), and security (vulnerability and hotspot) rules. 

There are a lot of expectations about security so we will explain some key concepts and write about how the security rules differ from others.

As with other types of rules, we try to raise no false positives; you should be confident that anything reported to you as an issue is really an issue.

Under the hood, SonarQube is based on different representations of the source code and technologies in order to be able to detect any kind of security issue:

  • Security-injection rules: There's a vulnerability here 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. To do this, SonarQube uses well-known taint analysis technology on source code which allows, for example, the detection of:
  • Security-configuration rules: Here there is a security issue because when calling a sensitive function, the wrong parameter (for example invalid cryptographic algorithm or TLS version) has been set or when a check (for example, a check_permissions() kind of function) was not done or not in the correct order, this problem is likely to appear often when the program is executed (no injected/complex attacks are required unlike in the previous category):
    • 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

These security issues are then divided into two categories: vulnerabilities and hotspots (see the main differences on the Security hotspots page). 

Security hotspots have been introduced for security protections that have no direct impact on the overall application's security. Most injection rules are vulnerabilities, for example, if a SQL injection is found, it is certain that a fix (input validation) is required, so this is a vulnerability. On the contrary, when creating a cookie, the 'HttpOnly' flag is an additional protection level (to reduce the impact when XSS vulnerabilities appear) but it is not always possible to implement or might not be relevant depending on the context of the application: therefore it's a hotspot.

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.

Which security-standards are covered

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

OWASP Top 10 security standards covered by Sonar for version 2021
CategoryPythonJS/TSJavaC#C/C++PHP
A01:Broken Access Control
Checkmark icon
Checkmark icon
Checkmark icon
Checkmark icon
Checkmark icon
Checkmark icon
A02: Cryptographic Failures 
Checkmark icon
Checkmark icon
Checkmark icon
Checkmark icon
Checkmark icon
Checkmark icon
A03: Injection
Checkmark icon
Checkmark icon
Checkmark icon
Checkmark icon

Checkmark icon
A04: Insecure Design
Checkmark icon
Checkmark icon
Checkmark icon
Checkmark icon
Checkmark icon
Checkmark icon
A05: Security Misconfiguration
Checkmark icon
Checkmark icon
Checkmark icon
Checkmark icon
Checkmark icon
Checkmark icon
A06: Vulnerable and Outdated Components

Checkmark icon
Checkmark icon
Checkmark icon
Checkmark icon
A07: Identification and Authentication Failures
Checkmark icon
Checkmark icon
Checkmark icon
Checkmark icon
Checkmark icon
Checkmark icon
A08: Software and Data Integrity Failures
Checkmark icon
Checkmark icon
Checkmark icon
Checkmark icon

Checkmark icon
A09: Security Logging and Monitoring Failures
Checkmark icon
Checkmark icon
Checkmark icon
Checkmark icon

Checkmark icon
A10: Server-Side Request Forgery
Checkmark icon
Checkmark icon
Checkmark icon
Checkmark icon

Checkmark icon
CWE Top 25 security standards covered by Sonar for version 2023
CategoryPythonJS/TSJavaC#C/C++PHP
CWE-787: Out-of-bounds Write



Checkmark icon

CWE-79:  Improper Neutralization of Input During
Web Page Generation ('Cross-site Scripting')
Checkmark icon
Checkmark icon
Checkmark icon
Checkmark icon

Checkmark icon
CWE-89: Improper Neutralization of Special
Elements used in an SQL Command ('SQL Injection')
Checkmark icon
Checkmark icon
Checkmark icon
Checkmark icon

Checkmark icon
CWE-416: Use After Free



Checkmark icon

CWE-78: Improper Neutralization of Special
Elements used in an OS Command
('OS Command Injection')
Checkmark icon
Checkmark icon
Checkmark icon
Checkmark icon

Checkmark icon
CWE-20: Improper Input Validation
Checkmark icon
Checkmark icon
Checkmark icon
Checkmark icon

Checkmark icon
CWE-125: Out-of-bounds Read



Checkmark icon

CWE-22: Improper Limitation of a Pathname
to a Restricted Directory ('Path Traversal')
Checkmark icon
Checkmark icon
Checkmark icon
Checkmark icon

Checkmark icon
CWE-352: Cross-Site Request Forgery (CSRF)
Checkmark icon
Checkmark icon
Checkmark icon
Checkmark icon

Checkmark icon
CWE-434: Unrestricted Upload of File with
Dangerous Type

Checkmark icon




CWE-862: Missing Authorization





CWE-476: NULL Pointer Dereference
Checkmark icon
Checkmark icon
Checkmark icon
Checkmark icon
Checkmark icon

CWE-287: Improper Authentication

Checkmark icon



CWE-190: Integer Overflow or Wraparound

Checkmark icon
Checkmark icon
Checkmark icon

CWE-502: Deserialization of Untrusted Data
Checkmark icon

Checkmark icon
Checkmark icon

Checkmark icon
CWE-77: Improper Neutralization of Special
Elements used in a Command ('Command Injection')
Checkmark icon
Checkmark icon
Checkmark icon
Checkmark icon

Checkmark icon
CWE-119: Improper Restriction of Operations
within the Bounds of a Memory Buffer




Checkmark icon

CWE-798: Use of Hard-coded Credentials
Checkmark icon
Checkmark icon
Checkmark icon
Checkmark icon
Checkmark icon
Checkmark icon
CWE-918: Server-Side Request Forgery (SSRF)
Checkmark icon
Checkmark icon
Checkmark icon
Checkmark icon

Checkmark icon
CWE-306: Missing Authentication for Critical Function





CWE-362: Concurrent Execution using Shared
Resource with Improper Synchronization
('Race Condition')






CWE-269: Improper Privilege Management
Checkmark icon
Checkmark icon




CWE-94: Improper Control of Generation of
Code ('Code Injection')
Checkmark icon
Checkmark icon
Checkmark icon
Checkmark icon

Checkmark icon
CWE-863: Incorrect Authorization





CWE-276: Incorrect Default Permissions





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:

How to propose new security 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.

Regarding the security-injection rules mentioned above, it's possible to extend the taint analysis configuration which allows the SonarQube engine to use new sources, sanitizers, validators and sinks within the homemade frameworks that you use. Security engine custom configuration is available as part of the Enterprise Edition and above.


Was this page helpful?

© 2008-2025 SonarSource SA. All rights reserved. SONAR, SONARSOURCE, SONARQUBE, and CLEAN AS YOU CODE are trademarks of SonarSource SA.

Creative Commons License