`security/detect-object-injection` false alarm on type safe key

[loynoir]

`security/detect-object-injection` false alarm on type safe key

[nzakas]

Bypass security/detect-object-injection when type safe.

What does this mean?

[loynoir]

@nzakas

Given

const kfoo = Symbol('foo')
const kbar = 'bar'
const o: Partial<Record<typeof kfoo | typeof kbar, 42>> = {}

I think below code are safe, right?

// eslint-disable-next-line security/detect-object-injection
o[kfoo] = 42
// eslint-disable-next-line security/detect-object-injection
o[kbar] = 42

[nzakas]

Again, I'm not quite sure what you're asking.

ESLint doesn't interpret code, it just looks for simple patterns. If you're implying that something in the first code block means the code in the second block shouldn't warn, that's not something this rule can do. It's not going to interpret TypeScript (which is expensive) to figure out if a later pattern would work.

[loynoir]

@nzakas

Quote reply from typescript-eslint/typescript-eslint#7194

Unlike ESLint core - 3rd party plugins aren't restricted to just supporting JS and can support TS and consume types.

For this reason we do not create extension rules for 3rd party rules - we are not looking to compete with other plugins in the community.

It would be nice to let security/detect-object-injection have better typescript support within eslint-community/eslint-plugin-security.

It's not going to interpret TypeScript (which is expensive) to figure out if a later pattern would work.

Compare to human time, machine time is not so expensive.

Given

• typescript obj[variable_key]

Would be nice to have option

• ignore security/detect-object-injection when variable_key is subset of keyof typeof obj

[nzakas]

As I mentioned, that type of check is expensive and not worth implementing. However, because this is an open source project, you can always copy the rule and make your own that does exactly what you want.