Yes, you should definitely prevent this, because it makes cheating very easy.
There are countless ways for a cheater to manipulate the network traffic sent from their machine. For example:
- Hooking of network APIs of the operating system
- Play man-in-the-middle on their network router
- Hacking your game client
- Cloning your game client
You might consider to just tell the users of your library/engine to slap an anti-cheat tool on their game when they don't want cheaters, but 3rd party ACTs are just an excuse for people who don't know how to develop inherently secure client/server applications. Also, when you search on this website for information about anti-cheat tools you will realize how flawed they are.
Never trust the client. The client is in the hands of the enemy! Each incoming network message should be examined carefully to check if that very client is allowed to perform that very action at this very moment, and reject it when it doesn't.
When you use the TCP protocol, each client has their own connection, so determining who sent the message is trivial. UDP is connectionless, but each UDP datagram has a source-IP and source-port you can use to determine its origin. When your client library doesn't create any new UDP sockets, these shouldn't change during a session.
When you want to be really paranoid, you might consider encrypting the network traffic with a stock encryption algorithm (never invent your crypto unless you have at least a Ph.D. in math and computer science) and a different key for each session exchanged using the diffie-hellman key exchange. But that level of security is usually overkill for a game and not worth the added complexity and performance overhead.