[yiminghe]

in case of prototype pollution

[jdmarshall]

Prototype pollution of the labels object? Why on earth are you running into this scenario and why should every inc() call on every Counter in every deployment pay a tax on that? I made the change you are reverting to reduce GC overhead from stat updates.

[jdmarshall]

This is not a general purpose Object detector, it’s used to identify the optional label parameter on set and inc calls.

If anything needs to be done here, the other way to go would be to detect if the first or second argument is a Number, which would reduce the amount of overhead for the subsequent input validation.

[yiminghe]

In our production environment, we accidentally overwrote Object.prototype, which caused an exception to be thrown during an inc operation, the service is unavailable. We would like to implement this change to address that issue. Furthermore, the use of for...in loops is no longer recommended, especially since the introduction of Object.keys().

[yiminghe]

From copilot

Assessment: Looks good to merge — this is a minimal, correct fix for the prototype-pollution issue.

PR summary
This PR tightens validateLabel() so it ignores inherited enumerable properties instead of walking the whole prototype chain. The change is paired with a regression test covering the Object.create({ injected: null }) case, which is the exact pattern that could otherwise let attacker-controlled prototype keys pass validation.

Merge readiness and risk assessment
Risk: Low.
The fix is precise and behaviorally correct: Object.keys(labels) only iterates own enumerable properties, so inherited properties no longer trigger validation against the initial label set.
The regression test directly covers the security scenario and should prevent future regressions.
I do not see a blocking issue in this patch.
Possible improvements
No additional change is required for this fix. This is a clean, focused security hardening patch and the test coverage matches the bug being addressed.