Protobuf: parsing of optional fields works if the incoming data contains multiple values for that field?

I have a gRPC server and the incoming messages contain fields that are marked as optional. As the client which sends data to the server runs in an untrusted environment, invalid or modified incoming messages are possible.

In a test I noticed that if the client sends multiple values for that field (like it was defined as repeated), protobuf simply ignores the multiple values and uses the last received value, instead of throwing an Exception.

Is there a possibility to switch behavior to something like a "strict mode" and let protobuf throw an error in such a case? Or at least detect such defect incoming messages?

Tested with com.google.protobuf:protobuf-java:3.23.3:

message Msg1 { 
    repeated string field = 1;
}
message Msg2 { 
    optional string field = 1;
}

Msg1 msg1 = Msg1.newBuilder().addField("value1").addField("value2").addField("value3").build();
byte[] data = msg1.msg1.toByteArray(); // serialization on client side

Msg2 msg2 = Msg2.parseFrom(data); // deserializationon on server side. How to make this fail if the format is different

System.out.println(msg.getField()); // outputs "value3"

> Or at least detect such defect incoming messages?

One way to detect any message that differs from the schema, is to re-encode the decoded message. That will force it to the canonical format, and if the message exactly matches the schema, the binary representations will be byte-for-byte equivalent.

However, I do not think you should do this.

If the message is untrusted, what good does it do you to detect one particular kind of modification? The sender can fully control all message data anyway. If you want to enforce message integrity, you'll need to add a cryptographic signature or HMAC.

The behavior when same field is present multiple times is "last one wins". Sometimes it is useful behavior, sometimes not. But there doesn't seem to be any compelling reason to throw an error for it, and I'm not aware of any protobuf library that supports doing that.

Apparently, not.

This happens with oneof's too. If a sender contrives to send more than one of the oneof's fields, the parser simply keeps the last one received.

It is pretty bizarre, especially to be so silent about it. The whole idea of a schema based serialisation system like GPB is that you can easily have an agreed contract / ICD / message set. They've managed to make it very hard to detect in code that the contract isn't actually met...

I suspect the reason they've done this goes back to why Google invented GPB in the first place, to store data within Google's own systems. They probably wanted something that could do pretty well, even if old data was a long way out of spec compared to the current version of a schema. For most of Google's stuff, it doesn't matter if things occassionally go wrong; analytics, search, etc aren't exact anyway, who cares if an old bit of data parses weirdly in some server somewhere?

Being more tidly minded than it appears Google are, I much prefer to use ASN.1; it's a much more capable serialiser in the first place, and it makes it very easy to enforce an ICD / contract.

When Google first announced GPB at a dev conference and the reasons why they'd done it, apparently someone in the crowd asked, "why didn't you just use ASN.1?", to which the answer was that Google had never heard of it, Google's developers not having used Google to search the Internet for "binary serialisation standards". Says it all, really.