CODEWITHSUNDEEP
javasonarlint
Tim
Tim

Reputation: 5361

SonarLint best practice for "hard coded password" false positives

SonarLint flags as blockers some variables in my code base. Ones like public static final String INVALID_PASSWORD = "Your password is invalid.";

SonarLint thinks that the variable might contain a hard coded password, which is a security risk. But in this case, the variable does not contain a password, it contains a message about a password.

I also have some like public static final String INVALID_PASSWORD = "INVALID_PASSWORD";, that are codes rather than strings, which SonarLint also flags.

What's the best practice for "fixing" this type of issue? Two solutions that come to mind are renaming the variable, and using a @SupressWarnings("code here") annotation.

Does SonarLint itself have a recommendation for this issue? Is an there an industry best practice?

Upvotes: 14

Views: 8761

Answers (3)

Kavitha
Kavitha

Reputation: 1

Renaming the variable name worked for me .

Example: previously it started with the text password like this: passwordCreationRules Then I changed to rulesForPassword something like Tip: Try avoiding using password text may be you can cut short it as pass or something like that which worked for me

Upvotes: 0

Romano
Romano

Reputation: 455

You should be able to mute the Sonar issue with something like:

@SuppressWarnings("squid:S2068") // This is not an hard coded password.

Annotated over the culprit.

Upvotes: 10

janos
janos

Reputation: 124648

If you are using SonarLint in connected mode with SonarQube, then you can safely mark this issue as a False Positive. That would be a recommended way to manage the quality of your software, but it requires SonarQube.

If you are not using SonarQube, then currently there's no (good) way to suppress the issue in SonarLint. It's quite possible that such feature will be implemented in SonarLint in the near future (this year).

Upvotes: 4

Related Questions