Just as a tangent, you may be interested in the web cryptography API https://w3c.github.io/webcrypto/Overview.html .
And regarding another tangent, for dynamic sites, one has to take into account "origin": https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy .
If the code will be running on localhost, this opens up the possibility for clashes, e.g., with
indexedDB database names,
localStorage keys, cookies, and
postMessage. Actually this could theoretically be seen as a feature instead of a bug, given its potential to restore to the web the kind of application-agnosticism we have enjoyed on our desktops (no application is any more privileged than others as to viewing or editing the data created by another application), but given that none of the above actually have APIs requiring the user be asked for permission, malicious sites opened under localhost could simply freely overwrite or manipulate databases, etc. also saved on localhost, so at the moment it would not be much of a feature in IPFS. (The only browser attempt I know of to solve the problem of application-agnosticism,
globalStorage was nixed in Firefox a long time ago, perhaps because they did not require user permission for that either.)
(I created a Firefox add-on at one point, AsYouWish, which allowed escalation of user privileges upon granularly informed user consent, and it had a means of shared user storage, but the add-on no longer works in modern Firefox (or Chrome) as I haven't updated it to work with WebExtensions, but something like that could be a solution, though it would probably need to be implemented with NativeMessaging, something I've been meaning to do with another local-friendly add-on, WebAppFind, which allowed for opening of local files on the desktop into web applications through double-click or "Open with..." rather than drag-and-drop, but I haven't gotten around to updating it either)
FWIW, some browsers like Chrome restrict the
file:// protocol from accessing scripts outside of its directory, but I haven't seen any restrictions on localhost, so one can't rely on paths (e.g., hosting in another non-child directory) for security here either.