Security-related rules

The SonarQube quality model is applied to an automated code review and analysis based on four types of rules.

The four rule types included in the SonarQube quality model are:

  • 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:

    • 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 Managing Security Hotspots page.

Security standards 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

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 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

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:

PreviousSoftware qualitiesNextBuilt-in rule tags

Last updated

Was this helpful?