I think I don't fully understand your challenge as stated, so I'm perhaps not able to give the response you're looking for.
With that said, let's take the way that Netflix implemented DRM via web crypto and encrypted media extensions. Assuming that an attacker is in a position to inject arbitrary code in the browser's execution, the attacker still cannot bypass the server-side implementation (otherwise it wouldn't be DRM). Unless there is an exploitable weakness in the cryptosystem on the client-side that can be meaningfully chained to the server-side, you need to control both areas of execution to break the crypto involved.
When you say "override calls to better ciphers", do you mean something like a downgrade attack, such as in TLS? It's true that you could masquerade the client as a device that is only capable of using a vulnerable type of encryption, but in that scenario the server-side can simply choose to not support it. In fact (again using Netflix as an example), it is more or less a requirement of these cryptosystems that the algorithm's work be distributed between a client and a server for exactly this reason.
If what you're talking about is more of a situation where a rogue software gains access to the DOM while you're using web crypto to have an OTR-encrypted, browser-based conversation with someone else, and they use your secret key in execution to decrypt the other parties' messages: sure. But I'm not sure what's special about that versus client-side takeover of any other cryptosystem. You could just as easily take over Signal on a jailbroken iPhone.
