Typescript disclosed Api Key

Rules and Languages New rules / language support
1

I find that there is no rule to detect disclosed api-keys like this case for the language typescript:

                    const authReq = request.clone({
                        setHeaders: {
                            Authorization: `Bearer ${res?.signInUserSession.idToken.jwtToken}`,
                            'x-api-key': environment.production
                                ? `asjdhaskjhccjkhsdas`
                                : `dasjhdajskhcajsdhqusadjhk`,
                        },

The compliant way should be:

                    const authReq = request.clone({
                        setHeaders: {
                            Authorization: `Bearer ${res?.signInUserSession.idToken.jwtToken}`,
                            'x-api-key': environment.production
                                ? `${environment.API_KEY_PROD}`
                                : `${environment.API_kEY_DEV}`,
                        },

Is it possible the existence of a rule to detect these cases?

2

Hey @Cristianrage!

We do have a number of rules for secrets detection that focus on supporting specific providers. The rules available to you vary on which product you’re using (SonarQube Community Build / Server / Cloud). Which are you using?

You’ve obfuscated the real keys (rightfully so!). Do they belong to a specific provider?

3

Hi @Colin

The keys from the code I’ve pasted are dummy keys, the real ones have been replaced after the finding and ofuscated.

I 've tested this case with two sonarqube instances:

Sonarqube Community edition 9.9.6.92038
Sonarqube Enterprise edition * Version 9.9.1 (build 69595)

The original api keys aren’t from a provider, there are from an api developed for an internal solution.

4

Hey there.

Normally I’d push you to try on a supported version of SonarQube, but this was simple enough for me to try and reproduce on SonarQube Cloud. I’m surprised that a Security Hotspot isn’t raised. I’ll flag this for attention.

1 Like
7

Hi @Cristianrage,

Thank you for reporting. Indeed, we should be catching such issues. I believe this rule should have triggered: RSPEC

I did a quick test and I believe it doesn’t trigger as you are using a ternary expression. I also checked that it doesn’t trigger within an object assignment. I’ve created a ticket to track this: Jira

Kind regards,
Michal