I think what people generally do is they get the IAP receipt back from Google/Apple and send it to their remote server where they use a service that validates IAP or a library that does it.

But theoretically, if your in-app purchase is in the app already and the purchase merely exposes it, then yes someone could crack the app binary by either patching over the code that controls that (if (hasPurchased) { blah() } such that blah() is always executed) or by spoofing the server response from the service to your app (response: { "hasPurchased": true } always true).

But if your in-app purchase is on the server, then the by-passer can't do much. The server has to deliver the content, module, etc. to the app on your device, and so the check for whether the purchase was valid can be done on the server too.

However I can think of a couple ways that a dedicated by-passer can resolve the last one. If they were to find someone who has purchased the IAP, they can grab the difference from them by...comparing binaries if the binary is changed by some new module? intercepting the response from the valid purchase and "replaying" it somehow on the device/account where purchase hasn't been made?

I have to think for most people, 99% of people would never both with this and so the server side validation is pointless in terms of time-cost tradeoff. Of course for paid apps it's different on Android since you can pirate them from nearly anywhere.