`MaskErrors` does not mask validation errors about strawberry

[erikwrede]

I believe this is by design and that there are two distinct cases of masking errors:

• don't leak unintended error information on accident (current implementation)
• don't leak private schema information (e.g. available fields) through validation

Both cases are valid and may be required on their own without implying the other case. Please keep in mind that both cases exclude parsing, but I don't see any immediate security risks from leaving these open.

An ideal PR would add your suggestion as a configurable option. Since this is a new feature, you could write an integration-style test with a basic schema and an invalid query that fails validation against the given schema.

Feel free to tag me on the PR regarding any additional questions, or ask on our Discord in the #development channel 😊

[alimony]

@erikwrede A configurable option on the MaskErrors class, or e.g. a MaskValidationErrors subclass of MaskErrors?

[erikwrede]

@alimony I'd prefer an option on the MaskErrors constructor. CCing @patrick91 for a second opinion.

[alimony]

@patrick91 What do you think?