Pruning a response does nothing since everything still goes across the network

Pruning the response would help validate your response schema is correct and that is delivering what was promised.

But you're right, if you have version skew and the client is expecting something else then it's not much help.

You could do it client-side so that if the server adds an optional field the client would immediately prune it off. If it removes a field, it could fill it with a default. At a certain point too much skew will still break something, but that's probably what you want anyway.

▲

hn_throwaway_99 2 days ago | parent | prev [-]

You're misunderstanding. In GraphQL, the server prunes the response object. That is, the resolver method can return a "fat" object, but only the object pruned down to just the requested fields is returned over the wire.

It is an important security benefit, because one common attack vector is to see if you can trick a server method into returning additional privileged data (like detailed error responses).

▲

JAlexoid a day ago | parent | next [-]

I would like to remind you that in most cases the GQL is not colocated on the same hardware as the services it queries.

Therefore requests between GQL and downstream services are travelling "over the wire" (though I don't see it as an issue)

Having REST apis that return only "fat" objects is really not the most secure way of designing APIs

▲

fastball a day ago | parent | prev [-]

"Just the requested fields" as requested by the client?

Because if so that is no security benefit at all, because I can just... request the fat fields.

	▲	hn_throwaway_99 10 hours ago \| parent \| next [-]
		I'll explain again, because this is not what I'm saying. In many REST frameworks, while you define the return object type that is sent back over the wire, by default, if the actual object you return has additional fields on it (even if they are found nowhere in the return type spec), those fields will still get serialized back to the client. A common attack vector is to try to get an API endpoint to return an object with, for example, extra error data, which can be very helpful to the attacker (e.g. things like stack traces). I'd have to search for them, but some major breaches occurred this way. Yes, many REST frameworks allow you to specify things like validators (the original comment mentioned zod), but these validators are usually optional and not always directly tied to the tools used to define the return type schema in the first place. So with GraphQL, I'm not talking about access controls on GraphQL-defined fields - that's another topic. But I'm saying that if your resolver method (accidentally or not) returns an object that either doesn't conform to the return type schema, or it has extra fields not defined in the schema (which is not uncommon), GraphQL guarantees those values won't be returned to the client.
	▲	hdjrudni 14 hours ago \| parent \| prev [-]
		I wanted to refute you but you're right. It's not a security benefit. With GQL the server is supposed to null out the fields that the user doesn't have access to, but that's not automagic or an inherent benefit to GQL. You have the same problem with normal REST. Or maybe less so because you just wouldn't design the response with those extra fields; you'd probably build a separate 'admin' or 'privileged' endpoint which is easier to lock down as a whole rather than individual fields.