SonarSource Rules
  • Products

    In-IDE

    Code Quality and Security in your IDE with SonarQube Ide

    IDE extension that lets you fix coding issues before they exist!

    Discover SonarQube for IDE

    SaaS

    Code Quality and Security in the cloud with SonarQube Cloud

    Setup is effortless and analysis is automatic for most languages

    Discover SonarQube Cloud

    Self-Hosted

    Code Quality and Security Self-Hosted with SonarQube Server

    Fast, accurate analysis; enterprise scalability

    Discover SonarQube Server
  • SecretsSecrets
  • ABAPABAP
  • AnsibleAnsible
  • ApexApex
  • AzureResourceManagerAzureResourceManager
  • CC
  • C#C#
  • C++C++
  • CloudFormationCloudFormation
  • COBOLCOBOL
  • CSSCSS
  • DartDart
  • DockerDocker
  • FlexFlex
  • GitHub ActionsGitHub Actions
  • GoGo
  • HTMLHTML
  • JavaJava
  • JavaScriptJavaScript
  • JSONJSON
  • JCLJCL
  • KotlinKotlin
  • KubernetesKubernetes
  • Objective CObjective C
  • PHPPHP
  • PL/IPL/I
  • PL/SQLPL/SQL
  • PythonPython
  • RPGRPG
  • RubyRuby
  • RustRust
  • ScalaScala
  • ShellShell
  • SwiftSwift
  • TerraformTerraform
  • TextText
  • TypeScriptTypeScript
  • T-SQLT-SQL
  • VB.NETVB.NET
  • VB6VB6
  • XMLXML
  • YAMLYAML
Java

Java static code analysis

Unique rules to find Bugs, Vulnerabilities, Security Hotspots, and Code Smells in your JAVA code

  • All rules 733
  • Vulnerability60
  • Bug175
  • Security Hotspot40
  • Code Smell458

  • Quick Fix 65
Filtered: 30 rules found
regex
    Impact
      Clean code attribute
        1. Character classes in regular expressions should not contain only one character

           Code Smell
        2. Superfluous curly brace quantifiers should be avoided

           Code Smell
        3. Non-capturing groups without quantifier should not be used

           Code Smell
        4. Regular expression quantifiers and character classes should be used concisely

           Code Smell
        5. Regular expressions should not contain empty groups

           Code Smell
        6. Regular expressions should not contain multiple spaces

           Code Smell
        7. The regex escape sequence \cX should only be used with characters in the @-_ range

           Bug
        8. Single-character alternations in regular expressions should be replaced with character classes

           Code Smell
        9. Reluctant quantifiers in regular expressions should be followed by an expression that can't match the empty string

           Code Smell
        10. Regex lookahead assertions should not be contradictory

           Bug
        11. Back references in regular expressions should only refer to capturing groups that are matched before the reference

           Bug
        12. Regular expressions should not overflow the stack

           Bug
        13. Regex boundaries should not be used in a way that can never be matched

           Bug
        14. Regex patterns following a possessive quantifier should not always fail

           Bug
        15. Character classes in regular expressions should not contain the same character twice

           Code Smell
        16. Unicode Grapheme Clusters should be avoided inside regex character classes

           Bug
        17. Unicode-aware versions of character classes should be preferred

           Code Smell
        18. Case insensitive Unicode regular expressions should enable the "UNICODE_CASE" flag

           Bug
        19. Names of regular expressions named groups should be used

           Code Smell
        20. Character classes should be preferred over reluctant quantifiers in regular expressions

           Code Smell
        21. Regular expressions should be syntactically valid

           Bug
        22. Regex alternatives should not be redundant

           Bug
        23. Regexes containing characters subject to normalization should use the CANON_EQ flag

           Code Smell
        24. Using slow regular expressions is security-sensitive

           Security Hotspot
        25. Alternatives in regular expressions should be grouped when used with anchors

           Bug
        26. Empty lines should not be tested with regex MULTILINE flag

           Code Smell
        27. Regular expressions should not be too complicated

           Code Smell
        28. Repeated patterns in regular expressions should not match the empty string

           Bug
        29. "String#replace" should be preferred to "String#replaceAll"

           Code Smell
        30. Regex patterns should not be created needlessly

           Code Smell

        Using slow regular expressions is security-sensitive

        intentionality - efficient
        security
        Security Hotspot
        • cwe
        • regex

        Most of the regular expression engines use backtracking to try all possible execution paths of the regular expression when evaluating an input, in some cases it can cause performance issues, called catastrophic backtracking situations. In the worst case, the complexity of the regular expression is exponential in the size of the input, this means that a small carefully-crafted input (like 20 chars) can trigger catastrophic backtracking and cause a denial of service of the application. Super-linear regex complexity can lead to the same impact too with, in this case, a large carefully-crafted input (thousands chars).

        This rule determines the runtime complexity of a regular expression and informs you of the complexity if it is not linear.

        Note that, due to improvements to the matching algorithm, some cases of exponential runtime complexity have become impossible when run using JDK 9 or later. In such cases, an issue will only be reported if the project’s target Java version is 8 or earlier.

        Ask Yourself Whether

        • The input is user-controlled.
        • The input size is not restricted to a small number of characters.
        • There is no timeout in place to limit the regex evaluation time.

        There is a risk if you answered yes to any of those questions.

        Recommended Secure Coding Practices

        To avoid catastrophic backtracking situations, make sure that none of the following conditions apply to your regular expression.

        In all of the following cases, catastrophic backtracking can only happen if the problematic part of the regex is followed by a pattern that can fail, causing the backtracking to actually happen. Note that when performing a full match (e.g. using String.matches), the end of the regex counts as a pattern that can fail because it will only succeed when the end of the string is reached.

        • If you have a non-possessive repetition r* or r*?, such that the regex r could produce different possible matches (of possibly different lengths) on the same input, the worst case matching time can be exponential. This can be the case if r contains optional parts, alternations or additional repetitions (but not if the repetition is written in such a way that there’s only one way to match it).
          • When using JDK 9 or later an optimization applies when the repetition is greedy and the entire regex does not contain any back references. In that case the runtime will only be polynomial (in case of nested repetitions) or even linear (in case of alternations or optional parts).
        • If you have multiple non-possessive repetitions that can match the same contents and are consecutive or are only separated by an optional separator or a separator that can be matched by both of the repetitions, the worst case matching time can be polynomial (O(n^c) where c is the number of problematic repetitions). For example a*b* is not a problem because a* and b* match different things and a*_a* is not a problem because the repetitions are separated by a '_' and can’t match that '_'. However, a*a* and .*_.* have quadratic runtime.
        • If you’re performing a partial match (such as by using Matcher.find, String.split, String.replaceAll etc.) and the regex is not anchored to the beginning of the string, quadratic runtime is especially hard to avoid because whenever a match fails, the regex engine will try again starting at the next index. This means that any unbounded repetition (even a possessive one), if it’s followed by a pattern that can fail, can cause quadratic runtime on some inputs. For example str.split("\\s*,") will run in quadratic time on strings that consist entirely of spaces (or at least contain large sequences of spaces, not followed by a comma).

        In order to rewrite your regular expression without these patterns, consider the following strategies:

        • If applicable, define a maximum number of expected repetitions using the bounded quantifiers, like {1,5} instead of + for instance.
        • Refactor nested quantifiers to limit the number of way the inner group can be matched by the outer quantifier, for instance this nested quantifier situation (ba+)+ doesn’t cause performance issues, indeed, the inner group can be matched only if there exists exactly one b char per repetition of the group.
        • Optimize regular expressions with possessive quantifiers and atomic grouping.
        • Use negated character classes instead of . to exclude separators where applicable. For example the quadratic regex .*_.* can be made linear by changing it to [^_]*_.*

        Sometimes it’s not possible to rewrite the regex to be linear while still matching what you want it to match. Especially when using partial matches, for which it is quite hard to avoid quadratic runtimes. In those cases consider the following approaches:

        • Solve the problem without regular expressions
        • Use an alternative non-backtracking regex implementations such as Google’s RE2 or RE2/J.
        • Use multiple passes. This could mean pre- and/or post-processing the string manually before/after applying the regular expression to it or using multiple regular expressions. One example of this would be to replace str.split("\\s*,\\s*") with str.split(",") and then trimming the spaces from the strings as a second step.
        • When using Matcher.find(), it is often possible to make the regex infallible by making all the parts that could fail optional, which will prevent backtracking. Of course this means that you’ll accept more strings than intended, but this can be handled by using capturing groups to check whether the optional parts were matched or not and then ignoring the match if they weren’t. For example the regex x*y could be replaced with x*(y)? and then the call to matcher.find() could be replaced with matcher.find() && matcher.group(1) != null.

        Sensitive Code Example

        The first regex evaluation will never end in JDK <= 9 and the second regex evaluation will never end in any versions of the JDK:

        java.util.regex.Pattern.compile("(a+)+").matcher(
        "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"+
        "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"+
        "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"+
        "aaaaaaaaaaaaaaa!").matches(); // Sensitive
        
        java.util.regex.Pattern.compile("(h|h|ih(((i|a|c|c|a|i|i|j|b|a|i|b|a|a|j))+h)ahbfhba|c|i)*").matcher(
        "hchcchicihcchciiicichhcichcihcchiihichiciiiihhcchi"+
        "cchhcihchcihiihciichhccciccichcichiihcchcihhicchcciicchcccihiiihhihihihi"+
        "chicihhcciccchihhhcchichchciihiicihciihcccciciccicciiiiiiiiicihhhiiiihchccch"+
        "chhhhiiihchihcccchhhiiiiiiiicicichicihcciciihichhhhchihciiihhiccccccciciihh"+
        "ichiccchhicchicihihccichicciihcichccihhiciccccccccichhhhihihhcchchihih"+
        "iihhihihihicichihiiiihhhhihhhchhichiicihhiiiiihchccccchichci").matches(); // Sensitive
        

        Compliant Solution

        Possessive quantifiers do not keep backtracking positions, thus can be used, if possible, to avoid performance issues:

        java.util.regex.Pattern.compile("(a+)++").matcher(
        "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"+
        "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"+
        "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"+
        "aaaaaaaaaaaaaaa!").matches(); // Compliant
        
        java.util.regex.Pattern.compile("(h|h|ih(((i|a|c|c|a|i|i|j|b|a|i|b|a|a|j))+h)ahbfhba|c|i)*+").matcher(
        "hchcchicihcchciiicichhcichcihcchiihichiciiiihhcchi"+
        "cchhcihchcihiihciichhccciccichcichiihcchcihhicchcciicchcccihiiihhihihihi"+
        "chicihhcciccchihhhcchichchciihiicihciihcccciciccicciiiiiiiiicihhhiiiihchccch"+
        "chhhhiiihchihcccchhhiiiiiiiicicichicihcciciihichhhhchihciiihhiccccccciciihh"+
        "ichiccchhicchicihihccichicciihcichccihhiciccccccccichhhhihihhcchchihih"+
        "iihhihihihicichihiiiihhhhihhhchhichiicihhiiiiihchccccchichci").matches(); // Compliant
        

        See

        • OWASP - Top 10 2017 Category A1 - Injection
        • CWE - CWE-400 - Uncontrolled Resource Consumption
        • CWE - CWE-1333 - Inefficient Regular Expression Complexity
        • owasp.org - OWASP Regular expression Denial of Service - ReDoS
        • stackstatus.net(archived) - Outage Postmortem - July 20, 2016
        • regular-expressions.info - Runaway Regular Expressions: Catastrophic Backtracking
        • docs.microsoft.com - Backtracking with Nested Optional Quantifiers
          Available In:
        • SonarQube IdeCatch issues on the fly,
          in your IDE
        • SonarQube CloudDetect issues in your GitHub, Azure DevOps Services, Bitbucket Cloud, GitLab repositories
        • SonarQube Community BuildAnalyze code in your
          on-premise CI
          Available Since
          9.1
        • SonarQube ServerAnalyze code in your
          on-premise CI
          Developer Edition
          Available Since
          9.1

        © 2008-2025 SonarSource SA. All rights reserved.

        Privacy Policy | Cookie Policy | Terms of Use