An API operation has been detected that allows credentials to travel over an unencrypted channel. OpenAPI security requirements and target servers definitions for an API operation will always override the respective global settings.

However, when these settings are not defined for an operation, they default to the globally specified values.

Global security requirements inform API consumers of the authentication and authorization parameters required to successfully interact with the API.

An empty Global security definition might enable attackers to interact with sensitive API endpoints and allow them to perform operations that should be restricted to specific user accounts with specific privileges.

Example 1: The following OpenAPI specification declares an empty global security definition. APIs that implement this specification might be vulnerable to unauthorized or unauthenticated access to sensitive operations.

    openapi: 3.0.3
    info:
      title: My API
      version: 1.0.0
    security:      

API operations define security requirements to inform API consumers of the authentication and authorization parameters required to successfully invoke them.

Operations that include an empty security definition might enable attackers to interact with sensitive API endpoints and allow them to perform actions that should be restricted to specific user accounts with explicit privileges.

Example 1: The following OpenAPI specification sets an empty security definition for a sensitive operation. This overrides globally defined security requirements and renders the createUsers operation vulnerable to unauthorized and unauthenticated access.

openapi: 3.0.0
info:
...
paths:
  /users:
    post:
      operationId: createUsers
      security: []
      responses:
        '201':
          ...

Unencrypted communication channels are prone to eavesdropping and tampering. Servicing client requests over an insecure communication channel allows attackers to perform man-in-the-middle attacks, and gives them access to read or modify the data in transit.

Always configure APIs to use custom error responses instead of relying on the underlying framework's default responses. Default responses might give detailed information about the error that occurred, and inadvertently leak sensitive information.

Attackers may leverage the additional information provided by a default error response to mount attacks targeting the framework, database, or other resources used by the API.

Global security requirements inform API consumers of the authentication and authorization parameters required to successfully interact with the API.

An absent global security definition might enable attackers to interact with sensitive API endpoints and allow them to perform operations that should be restricted to specific user accounts with specific privileges.

Example 1: The following OpenAPI specification neglects to declare a global security definition. APIs that implement this specification might be vulnerable to unauthorized or unauthenticated access to sensitive operations.

    openapi: 3.0.3
    info:
      title: My API
      version: 1.0.0
    ...

API operations define security requirements to inform API consumers of the authentication and authorization parameters required to successfully invoke them.

Operations that do not include a security definition might enable attackers to interact with sensitive API endpoints and allow them to perform actions that should be restricted to specific user accounts with explicit privileges.

Example 1: The following OpenAPI specification fails to set a security definition for a sensitive operation. Additionally, without a global security definition, the createUsers operation is vulnerable to unauthorized and unauthenticated access.

openapi: 3.0.0
info:
...
paths:
  /users:
    post:
      operationId: createUsers
      responses:
        '201':
        ...

The securitySchemes definition specifies the security mechanisms that may be used globally or by specific API operations.

The securitySchemes definition is typically specified under the reusable components object and is referenced globally or by specific operations to dictate security requirements for interaction.

Example 1: The following OpenAPI specification fails to define the securitySchemes definition.

    openapi: 3.0.3
    info:
      title: My API
      version: 1.0.0
    components:
     schemas:
        GeneralError:
          type: object
            properties:
             ...

Global security requirements inform API consumers of the authentication and authorization parameters required to successfully interact with the API.

Optional security requirement entries defined within the global security definition might enable attackers to interact with sensitive API endpoints and allow them to perform operations that should be restricted to specific user accounts with specific privileges.

Example 1: The following OpenAPI specification declares a global security definition with optional security via the empty {} item. APIs that implement this specification might be vulnerable to unauthorized or unauthenticated access to sensitive operations.

    openapi: 3.0.3
    info:
      title: My API
      version: 1.0.0
    security:
      - {}
      - oauth_auth:
        - write:users
        - read:users

API operations define security requirements to inform API consumers of the authentication and authorization parameters required to successfully invoke them.

Operations that make security optional might enable attackers to interact with sensitive API endpoints and allow them to perform actions that should be restricted to specific user accounts with explicit privileges.

Example 1: The following OpenAPI specification makes security optional by including an empty object {} in the security definition for a sensitive operation. This overrides globally defined security requirements and renders the createUsers operation vulnerable to unauthorized and unauthenticated access.

openapi: 3.0.0
info:
...
paths:
  /users:
    post:
      operationId: createUsers
      security: 
      - {}
      - oauth_auth:
          - write:users
          - read:users
      responses:
        '201':
          ...

Insecure authentication methods might allow attackers to gain administrative privileges and orchestrate a complete system compromise.

It is never a good idea to assign an empty string to a password variable. If the empty password is used to successfully authenticate against another system, then the corresponding account's security is likely compromised because it accepts an empty password. If the empty password is merely a placeholder until a legitimate value can be assigned to the variable, then it can confuse anyone unfamiliar with the code and potentially cause problems on unexpected control flow paths.

Example: This code initializes an empty password variable.

...
password = ''.
...

It is never a good idea to assign an empty string to a password variable. If the empty password is used to successfully authenticate against another system, then the corresponding account's security is likely compromised because it accepts an empty password. If the empty password is merely a placeholder until a legitimate value can be assigned to the variable, then it can confuse anyone unfamiliar with the code and potentially cause problems on unexpected control flow paths.

Example 1: The following code attempts to set default authentication credentials for URL requests, supplying an empty string for a password.

    ...
    URLRequestDefaults.setLoginCredentialsForHost(hostname, "scott", "");
    ...

The code in Example 1 indicates that the user account "scott" is configured with an empty password, which an attacker can easily guess. After the program ships, updating the account to use a non-empty password will require a code change.

Example 2: The following code initializes a password variable to an empty string, attempts to read a stored value for the password, and compares it against a user-supplied value.

    ...
    var storedPassword:String = "";
    var temp:String;

    if ((temp = readPassword()) != null) {
        storedPassword = temp;
    }

    if(storedPassword.equals(userPassword))
        // Access protected resources
        ...
    }
    ...

If readPassword() fails to retrieve the stored password due to a database error or another problem, then an attacker could trivially bypass the password check by providing an empty string for userPassword.

It is never a good idea to have an empty password. If the account protected by the empty password is compromised, the owners of the system must choose between security and availability because it can be extremely difficult to patch the system after the code is in production.

Example 1: The following code uses an empty password to authenticate a client certificate:

...
HttpRequest req = new HttpRequest();
req.setClientCertificate('mycert', '');
...

If the code runs successfully, it indicates that the certificate is configured with an empty password, which an attacker can easily guess.

It is never a good idea to assign an empty string to a password variable. If the empty password is used to successfully authenticate against another system, then the corresponding account's security is likely compromised because it accepts an empty password. If the empty password is merely a placeholder until a legitimate value can be assigned to the variable, then it can confuse anyone unfamiliar with the code and potentially cause problems on unexpected control flow paths.

Example 1:

    ...
    NetworkCredential netCred = new NetworkCredential("scott", "", domain);
    ...

If the code in Example 1 succeeds, it indicates that the network credential login "scott" is configured with an empty password, which an attacker can easily guess. After the program ships, updating the account to use a non-empty password will require a code change.

Example 2: The following code initializes a password variable to an empty string, attempts to read a stored value for the password, and compares it against a user-supplied value.

    ...
    string storedPassword = "";
    string temp;

    if ((temp = ReadPassword(storedPassword)) != null) {
        storedPassword = temp;
    }

    if(storedPassword.Equals(userPassword))
        // Access protected resources
        ...
    }
    ...

If readPassword() fails to retrieve the stored password due to a database error or another problem, then an attacker could trivially bypass the password check by providing an empty string for userPassword.

It is never a good idea to assign an empty string to a password variable. If the empty password is used to successfully authenticate against another system, then the corresponding account's security is likely compromised because it accepts an empty password. If the empty password is merely a placeholder until a legitimate value can be assigned to the variable, then it can confuse anyone unfamiliar with the code and potentially cause problems on unexpected control flow paths.

Example 1: The following code attempts to connect to a database with an empty password.

    ...
    rc = SQLConnect(*hdbc, server, SQL_NTS, "scott", SQL_NTS, "", SQL_NTS);
    ...

If the code in Example 1 succeeds, it indicates that the database user account "scott" is configured with an empty password, which an attacker can easily guess. After the program ships, updating the account to use a non-empty password will require a code change.

Example 2: The following code initializes a password variable to an empty string, attempts to read a stored value for the password, and compares it against a user-supplied value.

    ...
    char *stored_password = "";

    readPassword(stored_password);

    if(safe_strcmp(stored_password, user_password))
        // Access protected resources
        ...
    }
    ...

If readPassword() fails to retrieve the stored password due to a database error or another problem, then an attacker could trivially bypass the password check by providing an empty string for user_password.

It is never a good idea to assign an empty string to a password variable. If the empty password is used to successfully authenticate against another system, then the corresponding account's security is likely compromised because it accepts an empty password. If the empty password is merely a placeholder until a legitimate value can be assigned to the variable, then it can confuse anyone unfamiliar with the code and potentially cause problems on unexpected control flow paths.

Example 1: The following code attempts to connect to a database with an empty password.

    ...
    <cfquery name = "GetSSNs" dataSource = "users"
     username = "scott" password = "">
    SELECT   SSN
    FROM     Users
    </cfquery>
    ...

If the code in Example 1 succeeds, it indicates that the database user account "scott" is configured with an empty password, which an attacker can easily guess. After the program ships, updating the account to use a non-empty password will require a code change.

It is never a good idea to assign an empty string to a password variable. If the empty password is used to successfully authenticate against another system, then the corresponding account's security is likely compromised because it accepts an empty password. If the empty password is merely a placeholder until a legitimate value can be assigned to the variable, then it can confuse anyone unfamiliar with the code and potentially cause problems on unexpected control flow paths.

Example 1: The following code initializes a password variable to an empty string, attempts to read a stored value for the password, and compares it against a user-supplied value.

    ...
      var password = "";
      var temp;
      if ((temp = readPassword()) != null) {
        password = temp;
      }
      if(password == userPassword()) {
         // Access protected resources
        ...
      }
    ...

If readPassword() fails to retrieve the stored password due to a database error or another problem, then an attacker could trivially bypass the password check by providing an empty string for userPassword.

In the mobile environment, password management is especially important given that there is such a high chance of device loss.

It is never a good idea to assign an empty string to a password variable. If the empty password is used to successfully authenticate against another system, then the corresponding account's security is likely compromised because it accepts an empty password. If the empty password is merely a placeholder until a legitimate value can be assigned to the variable, then it can confuse anyone unfamiliar with the code and potentially cause problems on unexpected control flow paths.

Example: The following code attempts to connect to a database with an empty password.

...
response.SetBasicAuth(usrName, "")
...

If the code in the Example succeeds, it indicates that the database user account "scott" is configured with an empty password, which an attacker can easily guess. After the program ships, updating the account to use a non-empty password will require a code change.

It is never a good idea to assign an empty string to a password variable. If the empty password is used to successfully authenticate against another system, then the corresponding account's security is likely compromised because it accepts an empty password. If the empty password is merely a placeholder until a legitimate value can be assigned to the variable, then it can confuse anyone unfamiliar with the code and potentially cause problems on unexpected control flow paths.

Example 1: The following code attempts to connect to a database with an empty password.

    ...
    DriverManager.getConnection(url, "scott", "");
    ...

If the code in Example 1 succeeds, it indicates that the database user account "scott" is configured with an empty password, which an attacker can easily guess. After the program ships, updating the account to use a non-empty password will require a code change.

Example 2: The following code initializes a password variable to an empty string, attempts to read a stored value for the password, and compares it against a user-supplied value.

    ...
    String storedPassword = "";
    String temp;

    if ((temp = readPassword()) != null) {
        storedPassword = temp;
    }

    if(storedPassword.equals(userPassword))
        // Access protected resources
        ...
    }
    ...

If readPassword() fails to retrieve the stored password due to a database error or another problem, then an attacker could trivially bypass the password check by providing an empty string for userPassword.

In the mobile environment, password management is especially important given that there is such a high chance of device loss.
Example 3: The following code initializes username and password variables to empty strings, reads credentials from an Android WebView store if they have not been previously rejected by the server for the current request, and uses them to setup authentication for viewing protected pages.

...
webview.setWebViewClient(new WebViewClient() {
  public void onReceivedHttpAuthRequest(WebView view,
        HttpAuthHandler handler, String host, String realm) {
    String username = "";
    String password = "";

    if (handler.useHttpAuthUsernamePassword()) {
      String[] credentials = view.getHttpAuthUsernamePassword(host, realm);
      username = credentials[0];
      password = credentials[1];
    }
    handler.proceed(username, password);
  }
});
...

Similar to Example 2, if useHttpAuthUsernamePassword() returns false, an attacker will be able to view protected pages by supplying an empty password.

It is never a good idea to have an empty password. It also makes fixing the problem extremely difficult once the code is in production. The password cannot be changed without patching the software. If the account protected by the empty password is compromised, the owners of the system must choose between security and availability.
Example: The following code has an empty password to connect to an application and retrieve address book entries:

...
obj = new XMLHttpRequest();
obj.open('GET','/fetchusers.jsp?id='+form.id.value,'true','scott','');
...

This code will run successfully, but anyone can access when they know the username.

It is never a good idea to assign an empty string to a password variable. The use of empty passwords can introduce a significant point of weakness into an otherwise secure system. Even if the empty password is merely a placeholder until a legitimate value can be assigned to the variable, it can confuse anyone unfamiliar with the code and potentially cause problems on unexpected control flow paths.

Example 1: The following code attempts to connect to a database with an empty password:

...
rc = SQLConnect(*hdbc, server, SQL_NTS, "scott", SQL_NTS, "", SQL_NTS);
...

If the code in Example 1 succeeds, it indicates that the database user account "scott" is configured with an empty password, which an attacker can easily guess. After the program ships, updating the account to use a non-empty password will require a code change.

Example 2: The following code initializes a password variable to an empty string, attempts to read a stored value for the password, and compares it against a user-supplied value:

...
NSString *stored_password = "";

readPassword(stored_password);

if(safe_strcmp(stored_password, user_password)) {
    // Access protected resources
    ...
}
...

If readPassword() fails to retrieve the stored password due to a database error or another problem, then an attacker could trivially bypass the password check by providing an empty string for user_password.

It is never a good idea to assign an empty string to a password variable. If the empty password is used to successfully authenticate against another system, then the corresponding account's security is likely compromised because it accepts an empty password. If the empty password is merely a placeholder until a legitimate value can be assigned to the variable, then it can confuse anyone unfamiliar with the code and potentially cause problems on unexpected control flow paths.

Example: The following code attempts to connect to a database with an empty password.

<?php
    ...
    $connection = mysql_connect($host, 'scott', '');
    ...
?>

If the code in the Example succeeds, it indicates that the database user account "scott" is configured with an empty password, which an attacker can easily guess. After the program ships, updating the account to use a non-empty password will require a code change.

It is never a good idea to assign an empty string to a password variable. If the empty password is used to successfully authenticate against another system, then the corresponding account's security is likely compromised because it accepts an empty password. If the empty password is merely a placeholder until a legitimate value can be assigned to the variable, then it can confuse anyone unfamiliar with the code and potentially cause problems on unexpected control flow paths.

Example: The following code initializes an empty password variable.

DECLARE
    password VARCHAR(20);
BEGIN
    password := "";
END;

It is never a good idea to assign an empty string to a password variable. If the empty password is used to successfully authenticate against another system, then the corresponding account's security is likely compromised because it accepts an empty password. If the empty password is merely a placeholder until a legitimate value can be assigned to the variable, then it can confuse anyone unfamiliar with the code and potentially cause problems on unexpected control flow paths.

Example: The following code attempts to connect to a database with an empty password.

...
db = mysql.connect("localhost","scott","","mydb")
...

If the code in the Example succeeds, it indicates that the database user account "scott" is configured with an empty password, which an attacker can easily guess. After the program ships, updating the account to use a non-empty password will require a code change.

It is never a good idea to assign an empty string to a password variable. If the empty password is used to successfully authenticate against another system, then the corresponding account's security is likely compromised because it accepts an empty password. If the empty password is merely a placeholder until a legitimate value can be assigned to the variable, then it can confuse anyone unfamiliar with the code and potentially cause problems on unexpected control flow paths.

Example 1: The following code attempts to connect to a database with an empty password.

    ...
    conn = Mysql.new(database_host, "scott", "", databasename);
    ...

If the code in Example 1 succeeds, it indicates that the database user account "scott" is configured with an empty password, which an attacker can easily guess. After the program ships, updating the account to use a non-empty password will require a code change.

Due to the dynamic nature of Ruby, many functions also take an optional number of arguments, so the password may be set to "" as a default value when none is specified. In this case you also need to make sure that the correct number of arguments are specified in order to make sure a password is passed to the function.

It is never a good idea to assign an empty string to a password variable. If the empty password is used to successfully authenticate against another system, then the corresponding account's security is likely compromised because it accepts an empty password. If the empty password is merely a placeholder until a legitimate value can be assigned to the variable, then it can confuse anyone unfamiliar with the code and potentially cause problems on unexpected control flow paths.

Example: The following code attempts to connect to a Web Service with an empty password.

    ...
    ws.url(url).withAuth("john", "", WSAuthScheme.BASIC)
    ...

If the code in Example succeeds, it indicates that the database user account "john" is configured with an empty password, which an attacker can easily guess. After the program ships, updating the account to use a non-empty password will require a code change.

It is never a good idea to assign an empty string to a password variable. The use of empty passwords can introduce a significant point of weakness into an otherwise secure system. Even if the empty password is merely a placeholder until a legitimate value can be assigned to the variable, it can confuse anyone unfamiliar with the code and potentially cause problems on unexpected control flow paths.

Example 1: The following code attempts to connect to a database with an empty password:

...
let password = ""
let username = "scott"
let con = DBConnect(username, password)
...

If the code in Example 1 succeeds, it indicates that the database user account "scott" is configured with an empty password, which an attacker can easily guess. After the program ships, updating the account to use a non-empty password will require a code change.

Example 2: The following code initializes a password variable to an empty string, attempts to read a stored value for the password, and compares it against a user-supplied value:

...
var stored_password = ""

readPassword(stored_password)

if(stored_password == user_password) {
// Access protected resources
...
}
...

If readPassword() fails to retrieve the stored password due to a database error or another problem, then an attacker could trivially bypass the password check by providing an empty string for user_password.

It is never a good idea to assign an empty string to a password variable. If the empty password is used to successfully authenticate against another system, then the corresponding account's security is likely compromised because it accepts an empty password. If the empty password is merely a placeholder until a legitimate value can be assigned to the variable, then it can confuse anyone unfamiliar with the code and potentially cause problems on unexpected control flow paths.

Example 1: The following code attempts to connect to a database with an empty password.

    ...
    Dim con As New ADODB.Connection
    Dim cmd As New ADODB.Command
    Dim rst As New ADODB.Recordset

    con.ConnectionString = "Driver={Microsoft ODBC for Oracle};Server=OracleServer.world;Uid=scott;Passwd=;"
    ...

If the code in Example 1 succeeds, it indicates that the database user account "scott" is configured with an empty password, which an attacker can easily guess. After the program ships, updating the account to use a non-empty password will require a code change.

It is never a good idea to hardcode a password. Not only does hardcoding a password allow all of the project's developers to view the password, it also makes fixing the problem extremely difficult. After the code is in production, the password cannot be changed without patching the software. If the account protected by the password is compromised, the owners of the system must choose between security and availability.
Example: The following code hardcodes a password:

...
password = 'tiger'.
...

This code will run successfully, but anyone who has access to it will have access to the password. After the program ships, there is likely no way to change a password of "tiger" unless the program is patched. An employee with access to this information can use it to break into the system.

It is never a good idea to hardcode a password. Not only does hardcoding a password allow all of the project's developers to view the password, it also makes fixing the problem extremely difficult. After the code is in production, the password cannot be changed without patching the software. If the account protected by the password is compromised, the owners of the system must choose between security and availability.
Example: The following code sets default authentication credentials for URL requests, supplying a hardcoded string for a password:

...
URLRequestDefaults.setLoginCredentialsForHost(hostname, "scott", "tiger");
...

This code will run successfully, but anyone who has access to it will have access to the password. After the program ships, there is likely no way to change the user "scott" with a password of "tiger" unless the program is patched. An employee with access to this information can use it to break into the system. Even worse, if attackers have access to the binary for the application they can use one of many publicly available decompilers to access the disassembled code, which will contain the values of the passwords used.

It is never a good idea to hardcode a password. Not only does hardcoding a password make it visible to all the project's developers, it also makes fixing the problem extremely difficult. After the code is in production, the password cannot be changed without patching the software. If the account protected by the password is compromised, the owners of the system must choose between security and availability.

Example 1: The following code uses a hardcoded password to authenticate a client certificate:

...
HttpRequest req = new HttpRequest();
req.setClientCertificate('mycert', 'tiger');
...

This code will run successfully, but anyone who has access to it will have the password. Anyone with access to this information can use it to compromise the system. After the program is released, changing the password for the certificate is difficult.

It is never a good idea to hardcode a password. Not only does hardcoding a password allow all of the project's developers to view the password, it also makes fixing the problem extremely difficult. After the code is in production, the password cannot be changed without patching the software. If the account protected by the password is compromised, the owners of the system must choose between security and availability.
Example: The following code uses a hardcoded password to create a network credential:

...
NetworkCredential netCred =
           new NetworkCredential("scott", "tiger", domain);
...

This code will run successfully, but anyone who has access to it will have access to the password. After the program ships, there is likely no way to change the network credential user "scott" with a password of "tiger" unless the program is patched. An employee with access to this information can use it to break into the system. If attackers have access to the executable for the application they can disassemble the code, which will contain the values of the passwords used.

It is never a good idea to hardcode a password. Not only does hardcoding a password allow all of the project's developers to view the password, it also makes fixing the problem extremely difficult. After the code is in production, the password cannot be changed without patching the software. If the account protected by the password is compromised, the owners of the system must choose between security and availability.
Example: The following code uses a hardcoded password to connect to a database:

...
rc = SQLConnect(*hdbc, server, SQL_NTS, "scott",
                SQL_NTS, "tiger", SQL_NTS);
...

This code will run successfully, but anyone who has access to it will have access to the password. After the program ships, there is likely no way to change the database user "scott" with a password of "tiger" unless the program is patched. An employee with access to this information can use it to break into the system. If attackers have access to the executable for the application they can disassemble the code, which will contain the values of the passwords used.

It is never a good idea to hardcode a password. Not only does hardcoding a password allow all of the project's developers to view the password, it also makes fixing the problem extremely difficult. After the code is in production, the password cannot be changed without patching the software. If the account protected by the password is compromised, the owners of the system must choose between security and availability.
Example: The following code uses a hardcoded password to connect to a database:

...
MOVE "scott" TO UID.
MOVE "tiger" TO PASSWORD.
EXEC SQL
  CONNECT :UID
  IDENTIFIED BY :PASSWORD
  AT :MYCONN
  USING :MYSERVER
END-EXEC.
...

This code will run successfully, but anyone who has access to it will have access to the password. After the program ships, there is likely no way to change the database user "scott" with a password of "tiger" unless the program is patched. An employee with access to this information can use it to break into the system.