There’s a long history of attackers compromising popular web destinations, and exploiting those resources for monetary gain – the user populations are sometimes more valuable than the data on the compromised service.<p>Placing ‘exploit kits’ on compromised pages, and hitting their users’ with browser exploits or downloads continues to be popular, as is conducting ad-fraud. Cryptocurrency mining is yet another vector for attackers to monetize their hacks.<p>The problem is this; how does a browser verify that the code it has received from a website – is the same code the organization released to production?<p>The use of secure HTTPS communications – over TLS and SSL – prevents some attackers, such as those carrying out man-in-the-middle attacks from malicious wireless access points, or your local network. However, there’s a much larger attack surface upstream of HTTPS protections, Load Balancers, upstream enterprise components (an explosion with microservices trends), and the application servers themselves. Any of these components present a pivot point for attackers looking to exploit customers – because they can all introduce code before those connections are protected over the wire with HTTPS.<p>What we could use is an addition to web-standards, one that allows organizations to produce verifiable client-code, and browsers to validate that code. Long term, the dynamic aspects of JavaScript and modern development practices – such as manipulation of the Document Object Model at runtime – via WebSockets, Web Messages, contents of state in LocalStorage, and Ajax calls, mean that these efforts need to rely on a subset of JavaScript, safe from unintended injection attacks. Quick and Dirty - think GPG signatures.<p>Is there any work being done in this domain?