Security and privacy considerations

[xfq]

I'm not a security expert, here are just a few security and privacy related considerations I can think of for the WG to discuss. We can split them into separate issues if needed.

Add a separate Privacy Considerations section

Per Privacy Reviews Guidelines, we need to have a Privacy Considerations section, separate from Security Considerations.

Some things we may want to add about security and privacy include:

Recommendations to MiniApp implementers

We can add some recommendations for MiniApp implementers, such as:

• User agents should examine all vectors of attack from a MiniApp package and protect against them, such as attack of one MiniApp against another in the same user agent, or pretending to be another MiniApp or website in order to steal user information.

• MiniApp user agents should also check the package for malicious scripts, links, remote resources, and so on.

• User agents should isolate MiniApps from each other. On the same device, user A must not be able to read user B's data in the local storage; and different MiniApps must not read and write data in the local storage to each other.

• Some MiniApp user agents may collect user data. We should recommend user agents to be clear about the data being collected and how it is used.

In addition, many MiniApp implementations (like 1 2 3 4) disallow dynamic code loading like eval and new Function as a defense mechanism to stop XSS attacks. Currently, it is not mentioned in the Scripting Resources section. Should we consider standardizing this?

Recommendations to MiniApp developers

Should we write some security and privacy recommendations related to the developer of MiniApps, such as using HTTPS when requesting resources?

[espinr]

Good points @xfq. I've done the self-review questionnaire and I've detected some similar points we need to discuss and confirm. I'm not a security expert either, so there may be more points I haven't seen.

• MiniApps must be sandboxed (a MiniApp cannot access data from another one);
• But, MiniApp user agents may store and persist information across sessions (under the same app_id defined in the manifest? even with the version changes?);
• User agents may (possibly in a manner configured by the user) automatically delete stored data after some time;

The most important point to raise here is what you mentioned. MiniApp user agents are vulnerable to XSS attacks, concretely getting and processing external resources like images, data sources, and scripts. User agents should limit the attack vectors and mitigate the risks by implementing a Content Security Policy (CSP) to control the resources that a MiniApp can fetch or execute.

We could define a baseline CSP to

• prevent that third-party data in executable scripting functions and properties such as eval, new Function, onevent properties, setTimeout, href, src; and
• limiting the type of resources to be processed (i.e., javascript: URLs);
• prevent untrusted external data, limiting the origin of the external resources (i.e., images, stylesheets, media, and other scripts).

Some CSP directives could help us to solve the last point (i.e., default-src, connect-src, img-src, script-src, font-src, etc.). However, this solution is not valid for MiniApps because the manifest and components within the package don't have HTTP headers associated.

One solution could be introducing another member in the manifest to configure CSP and so restricting the external domains that could interact with the MiniApp.

Something like:

¨content-security-policy" : 
    {
        "default-src": [ "trusted.example.org" ],  // By default could be `none` for instance
    }
...  

Comments?

[xfq]

Sounds good. If we decide we want to fix this by introducing a new member in the manifest, maybe we can open a new issue in the manifest repo.

Also, do we need to point out the difference between the security model of MiniApps and web apps?

[xfq]

Another thing: if there is a link to a web page in the MiniApp, will a new browser be instance opened? If so, its browsing context is isolated from the MiniApp, which should be more secure. We might want to mention this in the security section.

[xfq]

We now have a separate Privacy Considerations section and some recommendations. I think this issue can be closed. Separate issues about the security and privacy considerations sections can be opened for discussion if needed.