| I think your threat model is that your application wants to execute or process (signed) resources that are stored on an untrusted third-party server (or one of your servers which is compromised). You're attempting to mitigate issues with a core "service worker" app which loads and verifies the resource before executing it. IANASEAIMMHH*, but - You're hosed if the core (service worker) app is compromised. - Adding more layers (a "core core" "secure cached wrapper") doesn't really help. If your core can be compromised, then so can your "core core". - You can't protect against a malicious user modifying your app; see the long, long history of copy-protection battles. This particularly applies to javascript; obfuscation doesn't work very well. Even if you could, the bad actor could run it in a modified JS engine. - In general, don't trust the client. The most robust app model is to do all the sensitive stuff on the server, with the client code establishing encrypted sessions and submitting transaction requests. If you do sensitive stuff on the client then you are creating a distributed application which partially runs on an untrustworthy platform you do not control and cannot even examine. - "Don't put all your eggs in one basket" does not apply to application code security. There is one egg (the "core", "core core", etc.) you must trust. Pulling some of the code out of that egg and putting it in another then means there are two eggs you must trust, and two different trust mechanisms. If you have a web app page that loads a "secure cached wrapper" which loads a "service worker" which loads a resource then you've got four things you must trust. You've got four times the surface area which can be compromised. From a security standpoint the best solution would be for the web app page to include everthing, or at least all the code. Constrain your must-trust eggs to as few baskets as possible and guard those baskets. - Every time you load code you've introduced a security weak point. From a security footprint standpoint, a one-time-loaded Single Page Application with no external resources would be best. The more typical code-load-per-page app, loading select trusted libraries and resources--not so much. AJAX apps using Really Cool NPM Libraries are a horror show. * I Am Not A Security Expert And It Makes My Head Hurt |