fix: avoid prototype-colliding names in execution values

[abishekgiri]

Summary

Fixes an issue where prototype-colliding property names (e.g., __proto__, constructor) could interfere with execution value handling.

Changes

• Ensured own-property checks are used when accessing execution values
• Prevent potential prototype chain collisions

Motivation

JavaScript objects can inherit properties from the prototype chain. Without proper checks, this can lead to unexpected behavior when handling execution values.

Testing

• Verified manually with edge-case inputs involving prototype properties
• Existing tests pass locally

[vercel]

@abishekgiri is attempting to deploy a commit to the The GraphQL Foundation Team on Vercel.

A member of the Team first needs to authorize it.

[abishekgiri]

Status update

• Fixed execution/values.ts so getArgumentValues() and getVariableValues() keep their null-prototype maps instead of reintroducing Object.prototype via object spread.
• Added regression coverage for omitted prototype-colliding names like toString in both resolver args and coerced variable values.
• Results: targeted mocha, eslint, and prettier checks passed for this change.
• tsc in this environment still reports existing external errors from ../node_modules/@types/react-dom, which are outside this PR.

[yaacovCR]

This would be a breaking change, and would have to land in v17, but we are considering doing so in:

• Use Object.create(null) over {} to avoid prototype issues #4634

See: #4634 (comment)

For background, see:

• Return normal objects for args and vars. #1056
• arg parameters in resolve don't inherit from Object express-graphql#177

Note that #1056 does not fully address the problem raised by graphql/express-graphql#177. In particular, while @leebyron gave a prototype to the args map itself, an input object arg still itself has no prototype -- just as ExecutionResult.data and its descendants have no prototype.

[yaacovCR]

Actually @abishekgiri -- on my box the new tests pass even without the suggested code changes. Is there an actual bug in this case

(we were considering doing so in the linked PR above just because the re-addition of the prototype didn't seem strictly necessary)

[abishekgiri]

@yaacovCR I dug through this end to end and verified that there is an actual bug here on plain \16.x.x. I checked the new variables-test.tscases against an unmodified16.x.xcheckout, and two of them fail without theexecution/values.tschange: omitted resolver argtoStringresolves to the inherited function instead of behaving as missing, andgetVariableValues(...).coerced.toStringalso resolves to the inherited function instead ofundefined`.

So I do think the bug is real. The harder part is branch compatibility: the current fix changes getArgumentValues() / getVariableValues() from returning plain objects with a prototype to null-prototype maps, and that seems to be the long-standing/documented behavior on 16.x.x. So my read is: real bug, but the current fix is probably 17.x.x material rather than a safe 16.x.x backport.`

[yaacovCR]

Ah, my box duplicates it now as well. I wonder if there would be a 16.x.x compatible fix possible, but agree that the direction of this fix would have to wait until 17.x.x.

[yaacovCR]

Ah, my box duplicates it now as well. I wonder if there would be a 16.x.x compatible fix possible, but agree that the direction of this fix would have to wait until 17.x.x.

Hmmm. actually, yet again looked closer, what the tests are testing is just the case @leebyron warns about in the changed comment, i.e. these objects have a prototype, and therefore one must be careful to not draw items from the prototype through an Object.hasOwn check or older equivalent. So there can't be a fix per se in 16.x.x -- although we can consider removing the prototype in 17.x.x.

[abishekgiri]

@yaacovCR Makes sense to me. Looking closer, this does seem to match the long-standing 16.x.xcontract that these returned objects have a prototype and consumers need an own-property check when reading from them. In that case, I agree there is not really a16.x.xfix to land here without changing behavior. This seems better tracked asv17 work alongside #4634.

[abishekgiri]

Following up here as well: after tracing the history in #1056 and #4631, I agree this does not look like a safe 16.x.x fix. The spread was kept intentionally so getArgumentValues() / getVariableValues() continue returning plain objects to user code, even after the internal accumulators moved to Object.create(null). That means the current change would alter the long-standing public contract on 16.x.x, so this seems better handled as v17 work alongside #4634 rather than something to merge from this PR.

[yaacovCR]

@abishekgiri I rebased this on 17.x.x and changed the PR base (after merging #4634). This PR now contains your tests and comment changes (as well as a small type change that could have also been in #4634 along with the similar type changes there).

Let me know if this looks good and will merge to 17.x.x.

[abishekgiri]

@yaacovCR This looks good to me on 17.x.x. Rebasing it after #4634 makes the direction much clearer, and the current scope also looks right: the regression tests, the updated comments, and the small type change all seem consistent with the null-prototype behavior there. I don’t see anything else I’d want to change on this PR from my side, so I’d be happy with merging it into 17.x.x.