Security maybe more of an issue today but WASM probably is not worse than JS in that regard (basically it's just another turing complete language). As others have said APIs are more problematic, which I suspect will ever get worse while browsers further and further try to transform from document viewers to application runtimes (think of such "brilliant" ideas like WebUSB). WASM is not the key issue here, it's running untrusted code on the client which, even if it's sometimes not outright harmful takes control away from the user in one way or antother. In the end the main difference is that it's now a feature of the Browser rather than a plugin which has a hard time to fit in nicely.
So many JVM bugs and a huge stdlib. WASM has no real lib, and when it does, it's security model is already restrictive... there's no disk, network, threads (yet), etc.
For example, you had to rewrite your apps to run as Java applets. You do not have to rewrite things to run on WebAssembly- all the existing C, C++, etc. code is compatible, up to the platform API.
But either way, I'd still take "use this object model for host GC interop" over "use this object model or leave the platform."
Then people started worrying about security and all of the Java applets broke because nobody wants to go through that code signing process.
I have to admit I don't know much about the security model of WebAssembly, but I wonder if it will become as annoying as Java in the future.
WebAssembly in browsers executes similarly to javascript in the same sandbox with the same platform APIs with the same kind of delivery methods, so I don't think we have that to worry about.