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. Custom permissions should not be defined in the "android.permission" namespace

           Vulnerability
        3. Exported component access should be restricted with appropriate permissions

           Vulnerability
        4. Struts validation forms should have unique names

           Vulnerability
        5. Struts filters should not miss their corresponding filter-map

           Vulnerability
        6. Default EJB interceptors should be declared in "ejb-jar.xml"

           Vulnerability
        7. Basic authentication should not be used

           Vulnerability

        Basic authentication should not be used

        responsibility - trustworthy
        security
        Vulnerability

          This rule is deprecated, and will eventually be removed.

          Basic authentication is a vulnerable method of user authentication that should be avoided. It functions by transmitting a Base64 encoded username and password. As Base64 is easy to recognize and reverse, sensitive data may be leaked this way.

          Why is this an issue?

          How can I fix it?

          More Info

          Basic authentication is a simple and widely used method of user authentication for HTTP requests. When a client sends a request to a server that requires authentication, the client includes the username and password (concatenated together and Base64 encoded) in the "Authorization" header of the HTTP request. The server verifies the credentials and grants access if they are valid. Every request sent to the server to a protected endpoint must include these credentials.

          Basic authentication is considered insecure for several reasons:

          • It transmits user credentials in plain text, making them susceptible to interception and eavesdropping.
          • It relies solely on the server’s ability to verify the provided credentials. There is no mechanism for additional security measures like multi-factor authentication or account lockouts after multiple failed login attempts.
          • It does not provide a way to manage user sessions securely. The client typically includes the credentials in every request, which creates more opportunities for an attacker to steal these credentials.

          These security limitations make basic authentication an insecure choice for authentication or authorization over HTTP.

          What is the potential impact?

          Basic authentication transmits passwords in plain text, which makes it vulnerable to interception by attackers.

          Session hijacking and man-in-the-middle attack

          If an attacker gains access to the network traffic, they can easily capture the username and password. Basic authentication does not provide any mechanism to protect against session hijacking attacks. Once a user is authenticated, the session identifier (the username and password) is sent in clear text with each subsequent request. If attackers can intercept one request, they can use it to impersonate the authenticated user, gaining unauthorized access to their account and potentially performing malicious actions.

          Brute-force attacks

          Basic authentication does not have any built-in protection against brute-force attacks. Attackers can repeatedly guess passwords until they find the correct one, especially if weak or commonly used passwords are used. This can lead to unauthorized access to user accounts and potential data breaches.

            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