Figure out implications of missing fields in JSON schema

[simitt]

So far Intake JSON schema defines all of the fields that will be processed (with the exception of custom, which is not indexed). Additional fields are explicitly allowed to keep future versions of the agents compatible with older server versions. In case additional fields are sent, they are not processed and neither indexed.
With the changes introduced in #3414 the Intake JSON schema for RUM only validates a part of the fields that are processed, as some fields were removed from the spec, but all Intake endpoints share the same model logic. Since the RUM endpoints are not protected, there is no protection from someone else sending up fields processed but not JSON schema validated.

We should investigate whether or not this could lead to runtime issues.

[jalvz]

From what I understood today, this is about testing non-defined yet processed fields to ensure that if rum sends them up (even if it shouldn't), the server doesn't panic.
Correct?

[simitt]

Yes, only the RUM endpoint is not protected by design, so it also concerns malicious uploads. All fields that are not validated by the JSON schema but processed by the server logic should be checked for not causing any server panics etc. when e.g. sent with unexpected values.

[jalvz]

Thanks for clarifying, I'll link this in the meta issue then.

[simitt]

Looking through the changes and sending data that are not part of the JSON spec anymore, I didn't find any situation where the server would panic. LGTM