Frontend security - Is it possible to limit access scope?-CodePudding

Given the growing size of frontend code, the concept of micro-frontend and module federation provided by Webpack 5 is a possible solution. However, considering the possibility that you are integrating code from other teams / 3rd parties, the foreign code could potentially try to access information it's not meant to by simply accessing the window object and iterating through its children.

This doesn't have to be critical information like passwords and credit cards, which are often isolated using an iframe. Less sensitive information like user emails, or tracking data could be collected and misused.

In this case, is there any technical set up that doesn't involve iframes that could limit the access scope of scripts? Is this something that could technically be implemented inside a WebAssembly program?

Edit: Yes, the conservative rule is to simply not run untrusted code. The question posed however is if it's technically possible to sandbox frontend code without using iframe to limit its access to information.

CodePudding user response：

Javascript is inherently "public", so at some point stuff you put in or get out will eventually be exposed, either through the network fetch/XHR, or through function execution.

There is a "private" pattern in javascript, which prevents snooping around inside an object -- where you explicitely define the methods/properties that are exposed:

window.myThing = (function(){

    var a = "a";
    var private_b = "b";

    function one(){
        return "one"
    }

    function private_two(){
        return private_b
    }

    return {
        public_a : a,
        public_one : one
    }

}());


for(var prop in window.myThing){
    console.log(prop, window.myThing[prop])
}

// ----------------------------------
// only the following properties 
// are exposed from the window scope:
// ----------------------------------
//    public_a as - a
//    public_one as ƒ one()

In theory, this type of pattern could allow for internal (non-exposed/non-traversable) methods and properties... and leverage some form of encryption for "ins and outs".