As Rapli says, the recieving end will only execute the code if it has been explicitly configured to do so.
While I see no reason to exchange executable code in this way (unless we are talking about code deployment to a remote system which is a very different conversation) there may well be good reasons for ensuring the integrity of data in such a manner.
As per usual, TLS makes ensuring CIA much simpler but, in the absence of a client certificate, it does not solve all the problems.
A complementary approach would be (for example) to use a simple signing mechanism creating a secure hash using a salt known by both ends and sending that with the message. But this does not protect against replay attacks. For that you need one-time passwords or sequentially numbered transactions. An alternative which merely reduces the window of opportunity would be to agree a TTL and include a timestamp in the (signed) payload.
But note that if you are going down the road of a shared secret, particularly if this is not using TLS, then you would get the added benefit of confidentiality by using that secret as an encryption key rather than just a salt for the hash.