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

        File existence checks followed by file creation should use atomic operations

        intentionality - logical
        security
        reliability
        Vulnerability
        • race-condition
        • toctou
        • cwe

        This rule raises an issue when code checks for file existence and then creates a file in separate operations, creating a race condition vulnerability.

        Why is this an issue?

        How can I fix it?

        More Info

        Checking if a file exists and then creating it in separate operations creates a Time-of-Check-Time-of-Use (TOCTOU) race condition. Between the existence check and the file creation, another process or thread might create or delete the file, leading to unexpected behavior.

        This race condition can cause several problems:

        • Security vulnerabilities: An attacker might create a symbolic link pointing to a sensitive file between the check and creation, causing your program to overwrite important system files.
        • Data corruption: If multiple processes try to create the same file simultaneously, they might interfere with each other’s operations.
        • Unpredictable behavior: Your program might fail unexpectedly when the file system state changes between operations.

        The root cause is that file system operations are not atomic by default. The gap between checking and acting gives other processes an opportunity to modify the file system state.

        What is the potential impact?

        Race conditions in file operations can lead to security vulnerabilities where attackers exploit the timing gap to redirect file operations to unintended locations. This can result in unauthorized file access, data corruption, or system compromise. In multi-threaded or multi-process environments, these issues can cause unpredictable application behavior and data integrity problems.

          Available In:
        • SonarQube CloudDetect issues in your GitHub, Azure DevOps Services, Bitbucket Cloud, GitLab repositories

        © 2025 SonarSource Sàrl. All rights reserved.

        Privacy Policy | Cookie Policy | Terms of Use