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
Go

Go static code analysis

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

  • All rules 94
  • Vulnerability21
  • Bug13
  • Security Hotspot14
  • Code Smell46
 
Tags
    Impact
      Clean code attribute
        1. File existence checks followed by file creation should use atomic operations

           Vulnerability
        2. Busy waiting loops should use proper synchronization

           Bug
        3. Context should not be stored in struct fields

           Code Smell
        4. Context parameters should be reused instead of creating new background contexts

           Code Smell
        5. Package imports should be consistent and avoid redundancy

           Code Smell
        6. Variables should be used

           Code Smell
        7. Consecutive function parameters with the same type should be grouped

           Code Smell
        8. HTTP response bodies should be closed to prevent resource leaks

           Bug
        9. Deprecated "InterfaceData" method should not be used

           Bug
        10. Named types should be used instead of anonymous structs for complex nested structures

           Code Smell
        11. Use "bytes.Equal" instead of "bytes.Compare" for equality checks

           Code Smell
        12. Single-method interface names should follow Go naming conventions

           Code Smell
        13. Variables in if short statements should be used beyond just the condition

           Code Smell
        14. Context cancellation functions should be deferred

           Code Smell
        15. Blank imports should be documented to explain their purpose

           Code Smell
        16. Function and method names should not use "Get" prefix

           Code Smell
        17. Custom error types must implement "Error()" method correctly

           Bug
        18. Semicolons should not be used unnecessarily

           Code Smell
        19. Database transactions should be properly handled with rollback mechanisms

           Bug
        20. Test functions should not call "t.Fatal" from separate goroutines

           Bug
        21. Import statements should be factored into a single block

           Code Smell
        22. Functions should follow Go's explicit error handling patterns

           Code Smell
        23. Credentials should not be hard-coded

           Vulnerability
        24. Hard-coded secrets are security-sensitive

           Security Hotspot
        25. Constructing arguments of system commands from user input is security-sensitive

           Security Hotspot
        26. Extracting archives should not lead to zip slip vulnerabilities

           Vulnerability
        27. JWT should be signed and verified with strong cipher algorithms

           Vulnerability
        28. Cipher algorithms should be robust

           Vulnerability
        29. Encryption algorithms should be used with secure mode and padding scheme

           Vulnerability
        30. Server hostnames should be verified during SSL/TLS connections

           Vulnerability
        31. Insecure temporary file creation methods should not be used

           Vulnerability
        32. Using publicly writable directories is security-sensitive

           Security Hotspot
        33. Passwords should not be stored in plaintext or with a fast hashing algorithm

           Vulnerability
        34. Using clear-text protocols is security-sensitive

           Security Hotspot
        35. HTTP request redirections should not be open to forging attacks

           Vulnerability
        36. Logging should not be vulnerable to injection attacks

           Vulnerability
        37. Server-side requests should not be vulnerable to forging attacks

           Vulnerability
        38. Server certificates should be verified during SSL/TLS connections

           Vulnerability
        39. Using weak hashing algorithms is security-sensitive

           Security Hotspot
        40. Multi-line comments should not be empty

           Code Smell
        41. Delivering code in production with debug features activated is security-sensitive

           Security Hotspot
        42. Cryptographic keys should be robust

           Vulnerability
        43. Weak SSL/TLS protocols should not be used

           Vulnerability
        44. Functions should not have identical implementations

           Code Smell
        45. Searching OS commands in PATH is security-sensitive

           Security Hotspot
        46. All branches in a conditional structure should not have exactly the same implementation

           Bug
        47. Cognitive Complexity of functions should not be too high

           Code Smell
        48. Database queries should not be vulnerable to injection attacks

           Vulnerability
        49. Creating cookies without the "HttpOnly" flag is security-sensitive

           Security Hotspot
        50. Cipher Block Chaining IVs should be unpredictable

           Vulnerability
        51. Non-existent operators like "=+" should not be used

           Bug
        52. Setting loose POSIX file permissions is security-sensitive

           Security Hotspot
        53. Go parser failure

           Code Smell
        54. Using pseudorandom number generators (PRNGs) is security-sensitive

           Security Hotspot
        55. Creating cookies without the "secure" flag is security-sensitive

           Security Hotspot
        56. XPath expressions should not be vulnerable to injection attacks

           Vulnerability
        57. I/O function calls should not be vulnerable to path injection attacks

           Vulnerability
        58. Formatting SQL queries is security-sensitive

           Security Hotspot
        59. OS commands should not be vulnerable to command injection attacks

           Vulnerability
        60. Hard-coded credentials are security-sensitive

           Security Hotspot
        61. Password hashing functions should use an unpredictable salt

           Vulnerability
        62. Boolean checks should not be inverted

           Code Smell
        63. Two branches in a conditional structure should not have exactly the same implementation

           Code Smell
        64. Related "if/else if" statements should not have the same condition

           Bug
        65. "switch" statements should not be nested

           Code Smell
        66. Identical expressions should not be used on both sides of a binary operator

           Bug
        67. All code should be reachable

           Bug
        68. Variables should not be self-assigned

           Bug
        69. "switch" statements should not have too many "case" clauses

           Code Smell
        70. Track lack of copyright and license headers

           Code Smell
        71. Functions and methods should not have too many lines

           Code Smell
        72. Control flow statements "if", "for" and "switch" should not be nested too deeply

           Code Smell
        73. Octal values should not be used

           Code Smell
        74. Using hardcoded IP addresses is security-sensitive

           Security Hotspot
        75. "switch" statements should have "default" clauses

           Code Smell
        76. "if ... else if" constructs should end with "else" clauses

           Code Smell
        77. Statements should be on separate lines

           Code Smell
        78. String literals should not be duplicated

           Code Smell
        79. Functions should not be empty

           Code Smell
        80. Unused function parameters should be removed

           Code Smell
        81. Local variable and function parameter names should comply with a naming convention

           Code Smell
        82. "switch case" clauses should not have too many lines

           Code Smell
        83. Useless "if(true) {...}" and "if(false){...}" blocks should be removed

           Bug
        84. Track uses of "TODO" tags

           Code Smell
        85. Track uses of "FIXME" tags

           Code Smell
        86. Boolean literals should not be redundant

           Code Smell
        87. Empty statements should be removed

           Code Smell
        88. Redundant pairs of parentheses should be removed

           Code Smell
        89. Nested blocks of code should not be left empty

           Code Smell
        90. Functions should not have too many parameters

           Code Smell
        91. Expressions should not be too complex

           Code Smell
        92. Files should not have too many lines of code

           Code Smell
        93. Lines should not be too long

           Code Smell
        94. Function names should comply with a naming convention

           Code Smell

        Passwords should not be stored in plaintext or with a fast hashing algorithm

        responsibility - trustworthy
        security
        Vulnerability
        • cwe
        • spring

        The improper storage of passwords poses a significant security risk to software applications. This vulnerability arises when passwords are stored in plaintext or with a fast hashing algorithm. To exploit this vulnerability, an attacker typically requires access to the stored passwords.

        Why is this an issue?

        How can I fix it?

        More Info

        Attackers who would get access to the stored passwords could reuse them without further attacks or with little additional effort.
        Obtaining the plaintext passwords, they could then gain unauthorized access to user accounts, potentially leading to various malicious activities.

        What is the potential impact?

        Plaintext or weakly hashed password storage poses a significant security risk to software applications.

        Unauthorized Access

        When passwords are stored in plaintext or with weak hashing algorithms, an attacker who gains access to the password database can easily retrieve and use the passwords to gain unauthorized access to user accounts. This can lead to various malicious activities, such as unauthorized data access, identity theft, or even financial fraud.

        Credential Reuse

        Many users tend to reuse passwords across multiple platforms. If an attacker obtains plaintext or weakly hashed passwords, they can potentially use these credentials to gain unauthorized access to other accounts held by the same user. This can have far-reaching consequences, as sensitive personal information or critical systems may be compromised.

        Regulatory Compliance

        Many industries and jurisdictions have specific regulations and standards to protect user data and ensure its confidentiality. Storing passwords in plaintext or with weak hashing algorithms can lead to non-compliance with these regulations, potentially resulting in legal consequences, financial penalties, and damage to the reputation of the software application and its developers.

        Recommended practices

        Use secure password hashing algorithms

        In general, you should rely on an algorithm that has no known security vulnerabilities. The MD5 and SHA-1 algorithms should not be used.

        Some algorithms, such as the SHA family functions, are considered strong for some use cases, but are too fast in computation and therefore vulnerable to brute force attacks, especially with bruteforce-attack-oriented hardware.

        To protect passwords, it is therefore important to choose modern, slow password-hashing algorithms. The following algorithms are, in order of strength, the most secure password hashing algorithms to date:

        1. Argon2
        2. scrypt
        3. bcrypt
        4. PBKDF2

        Argon2 should be the best choice, and others should be used when the previous one is not available. For systems that must use FIPS-140-certified algorithms, PBKDF2 should be used.

        Whenever possible, choose the strongest algorithm available. If the algorithm currently used by your system should be upgraded, OWASP documents possible upgrade methods here: Upgrading Legacy Hashes.

          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 ServerAnalyze code in your
          on-premise CI

        © 2025 SonarSource Sàrl. All rights reserved.

        Privacy Policy | Cookie Policy | Terms of Use