Best practice for S2068 false positives on route constants

Rules and Languages
1

Hi Team,

We are using SonarQube 2026.1.4 and seeing false positives from rule typescript:S2068 (and javascript:S2068).
In our case, route constants like FORGOT_PASSWORD and RESET_PASSWORD are flagged as hard-coded passwords, although values are only endpoint paths (not secrets).

Example pattern:

  • FORGOT_PASSWORD: /forgot-password
  • RESET_PASSWORD: /reset-password

Could you advise the best practice for this at scale across many projects and technologies?

Questions:

  1. Should we handle this with path-based exclusions for S2068 (routes/router files)?
  2. Or should we tune passwordWords in the Quality Profile?
  3. What is the recommended governance model to avoid too many project-specific exceptions while keeping real secret detection strong?

Thanks.

2

Hi @ckonca, thanks for the detailed report!

Based on the examples you’ve shared, these should actually already be handled correctly by the rule. Let me walk through why, and then ask for a reproducer so we can confirm what’s happening on your end.

How the rule filters URL paths

The JavaScript/TypeScript implementation of S2068 has an explicit set of characters that mark a value as not a credential. From the rule source (rule.ts):

const NON_CREDENTIAL_CHARS = /[\s/["'\]<>]/;

A value is only considered suspicious if it passes all of these checks:

function findValueSuspect(node): boolean {
  if (isStringLiteral(node)) {
    const value = node.value;
    return (
      value.length >= MIN_PASSWORD_LENGTH &&
      !NON_CREDENTIAL_CHARS.test(value) &&  // forward slash disqualifies immediately
      !isExcludedSecretValue(value) &&
      hasHighEntropy(value)
    );
  }
  ...
}

The forward slash / is explicitly included in NON_CREDENTIAL_CHARS, so any string containing / is immediately excluded from raising an issue, before entropy is even checked.

This is confirmed in the rule’s unit tests (unit.test.ts), where URL path values are listed as valid (non-flagged) cases:

// URL path segments (contain slashes)
{ code: `const reset_password_url = "/api/auth/reset_password/";`, options },
{ code: `const apiEndpoints = { createpassword: '/v1/security/createpassword' };`, options },

These are very close to your examples of FORGOT_PASSWORD: '/forgot-password' and RESET_PASSWORD: '/reset-password'.

Could you share a minimal reproducer?

Since the rule’s logic should already exclude these, I’d like to understand exactly what’s being flagged in your case. A few things that would help:

  1. The code snippet being flagged. What does the string value looks like (does it include the leading /?)
  2. Whether the issue is reported as typescript:S2068 or javascript:S2068 or possibly secrets:S2068 (a distinct rule from the SonarText engine with different logic)
  3. Your SonarQube version and the JS/TS plugin version (visible under Administration → Marketplace)

A small self-contained .ts file that reproduces the issue, along with the exact rule key shown in the issue details, would be ideal. That’ll let us test against the same conditions and pinpoint whether this is a version gap or a different rule triggering than expected.

Thanks,

Stevan

3

Please tag the language, to improve searching.