False positive for B105 / Possible hardcoded password

[linusjf]

Describe the bug

A false positive is produced for an url string that is spread over two lines despite the use of the suppression "# nosec".

REQUEST_TOKEN_URL = "https://api.twitter.com/oauth/request_token?\
oauth_callback=oob&x_auth_access_type=write"   # nosec

Reproduction steps

1. Use above snippet in your code
2. Run bandit on the source.

Expected behavior

There should be no violation reported in the bandit report.

Bandit version

1.7.4 (Default)

Python version

3.11.2 (Default)

Additional context

None

[Omarosman2000]

Have you tried using Python 3.7? On my machine, using Python 3.7, when I include the (#nosec) at the end of the broken URL to a multiple line, I don't get any (possible hard-coded password). But, when I erase the (#nosec) at the end of the broken URL to a multiple line, I do get a (possible hard-coded password). @Fernal73

[linusjf]

Have you tried using Python 3.7? On my machine, using Python 3.7, when I include the (#nosec) at the end of the broken URL to a multiple line, I don't get any (possible hard-coded password). But, when I erase the (#nosec) at the end of the broken URL to a multiple line, I do get a (possible hard-coded password). @Fernal73

No, I haven't. https://wiki.termux.com/wiki/Python

[Omarosman2000]

To prevent false positives when searching for hardcoded passwords, I added additional checks to ensure that the string being searched for is not part of a larger word or is not a false positive.

Here are some modifications that I made to the regular expressions in this code:

1) I modified 'RE WORDS to include word boundary anchors "\b around each word. This will ensure that the regular expression matches only complete words and not parts of words.  2) I also modified RE CANDIDATES to include a negative look-behind assertion (?<I (w) before the candidate string. This will prevent the regular expression from matching strings that are part of larger words.