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
XML

XML static code analysis

Unique rules to find Bugs and Code Smells in your XML code

  • All rules 37
  • Vulnerability7
  • Bug5
  • Security Hotspot9
  • Code Smell16
 
Tags
    Impact
      Clean code attribute
        1. Components should be explicitly exported

           Vulnerability
        2. Defining a single permission for read and write access of content providers is security-sensitive

           Security Hotspot
        3. Custom permissions should not be defined in the "android.permission" namespace

           Vulnerability
        4. Allowing application backups is security-sensitive

           Security Hotspot
        5. Requesting dangerous Android permissions is security-sensitive

           Security Hotspot
        6. Exported component access should be restricted with appropriate permissions

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

           Security Hotspot
        8. Receiving intents is security-sensitive

           Security Hotspot
        9. Having a permissive Cross-Origin Resource Sharing policy is security-sensitive

           Security Hotspot
        10. Delivering code in production with debug features activated is security-sensitive

           Security Hotspot
        11. Hibernate should not update database schemas

           Bug
        12. "DefaultMessageListenerContainer" instances should not drop messages during restarts

           Bug
        13. "SingleConnectionFactory" instances should be set to "reconnectOnException"

           Bug
        14. pom elements should be in the recommended order

           Code Smell
        15. Dependencies should not have "system" scope

           Bug
        16. Deprecated "${pom}" properties should not be used

           Code Smell
        17. Artifact ids should follow a naming convention

           Code Smell
        18. Group ids should follow a naming convention

           Code Smell
        19. Track uses of disallowed dependencies

           Code Smell
        20. Struts validation forms should have unique names

           Vulnerability
        21. "action" mappings should not have too many "forward" entries

           Code Smell
        22. Struts filters should not miss their corresponding filter-map

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

           Security Hotspot
        24. EJB interceptor exclusions should be declared as annotations

           Code Smell
        25. Default EJB interceptors should be declared in "ejb-jar.xml"

           Vulnerability
        26. Basic authentication should not be used

           Vulnerability
        27. Newlines should follow each element

           Code Smell
        28. XML parser failure

           Code Smell
        29. Hard-coded credentials are security-sensitive

           Security Hotspot
        30. XML files containing a prolog header should start with "<?xml" characters

           Bug
        31. Track breaches of an XPath rule

           Code Smell
        32. Sections of code should not be commented out

           Code Smell
        33. Track uses of "TODO" tags

           Code Smell
        34. Track uses of "FIXME" tags

           Code Smell
        35. Source code should be indented consistently

           Code Smell
        36. Tabulation characters should not be used

           Code Smell
        37. Lines should not be too long

           Code Smell

        Delivering code in production with debug features activated is security-sensitive

        consistency - conventional
        security
        Security Hotspot
        • cwe
        • error-handling
        • debug
        • android
        • user-experience

        Development tools and frameworks usually have options to make debugging easier for developers. Although these features are useful during development, they should never be enabled for applications deployed in production.

        Activating a development feature in production can have an important range of consequences depending on its use:

        • Technical information leak; generally by disclosing verbose logging information to the application’s user.
        • Arbitrary code execution; generally with a parameter that will allow the remote debugging or profiling of the application.

        In all cases, the attack surface of an affected application is increased. In some cases, such features can also make the exploitation of other unrelated vulnerabilities easier.

        Ask Yourself Whether

        • The development of the app is completed and the development feature is activated.
        • The app is distributed to end users with the development feature activated

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

        Recommended Secure Coding Practices

        Applications should be released without any development feature activated. When such features are required when in the development process of the application, they should only apply to a build variant that is dedicated to development environments. That variant should not be set as the default build configuration to prevent any unattended development feature exposition.

        Sensitive Code Example

        In AndroidManifest.xml the android debuggable property is set to true. The application will therefore be debuggable.

        <application
          android:icon="@mipmap/ic_launcher"
          android:label="@string/app_name"
          android:roundIcon="@mipmap/ic_launcher_round"
          android:supportsRtl="true"
          android:debuggable="true"
          android:theme="@style/AppTheme">
        </application>  <!-- Sensitive -->
        

        In a web.config file, the customErrors element’s mode attribute is set to Off. The application will disclose unnecessarily verbose information to its users upon error.

        <configuration>
          <system.web>
            <customErrors mode="Off" /> <!-- Sensitive -->
          </system.web>
        </configuration>
        

        Compliant Solution

        In AndroidManifest.xml the android debuggable property is set to false:

        <application
          android:icon="@mipmap/ic_launcher"
          android:label="@string/app_name"
          android:roundIcon="@mipmap/ic_launcher_round"
          android:supportsRtl="true"
          android:debuggable="false"
          android:theme="@style/AppTheme">
        </application> <!-- Compliant -->
        

        In a web.config file, the customErrors element’s mode attribute is set to On:

        <configuration>
          <system.web>
            <customErrors mode="On" /> <!-- Compliant -->
          </system.web>
        </configuration>
        

        See

        • OWASP - Top 10 2021 Category A5 - Security Misconfiguration
        • OWASP - Top 10 2017 Category A3 - Sensitive Data Exposure
        • OWASP - Mobile AppSec Verification Standard - Code Quality and Build Setting Requirements
        • OWASP - Mobile Top 10 2016 Category M10 - Extraneous Functionality
        • CWE - CWE-489 - Active Debug Code
        • CWE - CWE-215 - Information Exposure Through Debug Information
        • developer.android.com - Prepare for release
        • learn.microsoft.com - ASP.NET Error Handling
          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