Because it is easy to extract strings from an application source code or binary, passwords should not be hard-coded. This is particularly true for -applications that are distributed or that are open-source.
+Hard-coding credentials in source code or binaries makes it easy for attackers to extract sensitive information, especially in distributed or +open-source applications. This practice exposes your application to significant security risks.
+This rule flags instances of hard-coded credentials used in database and LDAP connections. It looks for hard-coded credentials in connection +strings, and for variable names that match any of the patterns from the provided list.
In the past, it has led to the following vulnerabilities:
-Passwords should be stored outside of the code in a configuration file, a database, or a password management service.
-This rule flags instances of hard-coded passwords used in database and LDAP connections. It looks for hard-coded passwords in connection strings, -and for variable names that match any of the patterns from the provided list.
-There would be a risk if you answered yes to any of those questions.
-+How to fix it
+Credentials should be stored in a configuration file that is not committed to the code repository, in a database, or managed by your cloud +provider’s secrets management service. If a password is exposed in the source code, it must be changed immediately.
+Code Examples
+Noncompliant code example
+String username = "steve"; String password = "blue"; Connection conn = DriverManager.getConnection("jdbc:mysql://localhost/test?" + - "user=" + username + "&password=" + password); // Sensitive + "user=" + username + "&password=" + password); // Noncompliant-Compliant Solution
-+Compliant solution
+String username = getEncryptedUser(); String password = getEncryptedPassword(); Connection conn = DriverManager.getConnection("jdbc:mysql://localhost/test?" + "user=" + username + "&password=" + password);-See
+Resources
Because it is easy to extract strings from an application source code or binary, secrets should not be hard-coded. This is particularly true for -applications that are distributed or that are open-source.
-In the past, it has led to the following vulnerabilities:
-Secrets should be stored outside of the source code in a configuration file or a management service for secrets.
+Hard-coding secrets in source code or binaries makes it easy for attackers to extract sensitive information, especially in distributed or +open-source applications. This practice exposes credentials and tokens, increasing the risk of unauthorized access and data breaches.
This rule detects variables/fields having a name matching a list of words (secret, token, credential, auth, api[_.-]?key) being assigned a pseudorandom hard-coded value. The pseudorandomness of the hard-coded value is based on its entropy and the probability to be human-readable. The randomness sensibility can be adjusted if needed. Lower values will detect less random values, raising potentially more false positives.
-There would be a risk if you answered yes to any of those questions.
-+How to fix it
+Secrets should be stored in a configuration file that is not committed to the code repository, in a database, or managed by your cloud provider’s +secrets management service. If a secret is exposed in the source code, it must be rotated immediately.
+Code Examples
+Noncompliant code example
+private static final String MY_SECRET = "47828a8dd77ee1eb9dde2d5e93cb221ce8c32b37"; public static void main(String[] args) { MyClass.callMyService(MY_SECRET); }-Compliant Solution
+Compliant solution
Using AWS Secrets Manager:
-+import software.amazon.awssdk.services.secretsmanager.model.GetSecretValueRequest; import software.amazon.awssdk.services.secretsmanager.model.GetSecretValueResponse; @@ -80,15 +66,15 @@-Compliant Solution
MyClass.callMyService(secret); }See
+Resources