API Mass Assignment Mitigation about apollo-server HOT 2 CLOSED

I'd be disinclined to make this change. The GraphQL-over-HTTP spec (which to some degree we try to follow and to some degree we try to improve) doesn't prescribe behavior here, just stating

All other property names are reserved for future expansion; if implementors need to add additional information to a request they MUST do so via other means, the RECOMMENDED approach is to add an implementor-scoped entry to the {extensions} object.

GraphQL requests didn't support extensions originally. When we tried to add it in our clients, we found it pretty frustrating that a few GraphQL servers had exactly the behavior you described above of rejecting POST bodies with unknown keys — it meant any feature that used request-side extensions had to carefully be opt-in so that you wouldn't accidentally use it against one of these stricter servers. I wouldn't want Apollo Server to cause the same sort of issue for the future.

You could posit that this issue was unique to adding extensions since now that extensions exists, it is itself the right place to put new keys. But the GraphQL spec itself could add new top-level fields here, and it would be imaginable that some field could be added that would be OK if the server didn't know about it, so I'd rather not paint us into a corner and prevent those sorts of gradual-adoption new features by rejecting these requests immediately.

It looks like our plugin API more or less suits your use case. If many people have the same issue we could consider adding it to the docs but for now I'd prefer us to not make our servers stricter unless there's an actual security issue being triggered.

from apollo-server.

That reasoning makes sense. Thanks for the history on the extensions object.

from apollo-server.