... I can imagine, though low probability, that my message might contain the values "10 and 13" after each other when they are not the stop bytes.
A situation when a portion of data is equal to terminating sequence should be considered when designing the format of a serial data packet. Another thing to consider is that any character can get corrupted or lost during transmission. A start character, a stop character, a data payload byte, a checksum or CRC byte, a forward error correction byte aren't immune to corruption. The framing mechanism has to be able to detect when a packet has corrupt data.
There a several ways to approach all this.
I'm making the working assumption that packets are framed only with the serial bytes. Handshake lines aren't used for framing. Time delays aren't used for framing.
Send packet length
Send the length of the packet in the beginning, instead of [or in addition to] the terminating character at the end.
pros: Payload is sent in a efficient binary format.
cons: Need to know the packet length at the start of the transmission.
Escape the special characters
Escape the special characters when sending the payload data. This is already explained in a an earlier answer.
pros: Sender doesn't need to know the length of the packet at the beginning of the transmission.
cons: Slightly less efficient, depending on how many payload bytes need to be escaped.
Payload data encoded such that it can't contain start and stop characters
The payload of the packet is encoded such that it can't contain the start or stop characters. Usually, this is done by sending numbers as their ASCII or Hex-ASCII representation.
pros: Human-readable with common terminal programs. No need for code to handle escaping. No need to know the length of the packet at the start of the transmission
cons: Lower efficiency. For one byte of payload data, several bytes are sent.