S6418 — Secrets should not be hard-coded

Why is this an issue?

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/properties 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.

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 MySecret As String = "47828a8dd77ee1eb9dde2d5e93cb221ce8c32b37"

Compliant solution

Private MySecret As String = Environment.GetEnvironmentVariable("MYSECRET")

Resources

• OWASP - Top 10 2021 Category A7 - Identification and Authentication Failures
• OWASP - Top 10 2017 Category A2 - Broken Authentication
• CWE - CWE-798 - Use of Hard-coded Credentials
• MSC - MSC03-J - Never hard code sensitive information