You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As mentioned in w3c/miniapp-packaging#46 and #31, MiniApps user agents are vulnerable to XSS attacks. So we should define a mechanism to enable user agents to restrict the origin of the external resources (i.e., images, stylesheets, media, and other scripts).
About static resources
Most of the MiniApp implementations support external -they are not within the MiniApp package- media resources included in the user interaction components (e.g., Baidu, WeChat, QQ, Quick Apps...), also stylesheets and fonts. In these cases, I haven't found specific limitations in the sources, only constraints related to file formats.
About dynamic resources
Network operations from scripts are different, and some MiniApp versions limit dynamic fetches, downloads, and other networking communications. In most of the cases, they require a safelist of domains in advance (e.g., Baidu, ByteDance, QQ, Weixin). Through different means, developers have to communicate with the platform as a previous step, so this safelist is not included in the configuration manifests. I see a case of a flag in the MiniApp manifest to specify if the external URLs must be checked or not. "settings": { "urlCheck" : boolean }.
A CSP (Content Security Policy)
With these scenarios, we could consider configuring a CSP and restricting the external domains that could dynamically interact with the MiniApp.
Existing CSP directives would allow us to restrict the source of the HTTP resources 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. So, one solution is to introduce another member in the manifest to control, at least, the safelist of domains for the network operations performed by the scrips.
Most of the MiniApp implementations support external -they are not within the MiniApp package- media resources included in the user interaction components (e.g., Baidu, WeChat, QQ, Quick Apps...), also stylesheets and fonts.
My understanding is that the URLs unregistered in backend MiniApp platform (including resource URL, page URL, etc.) are not permitted by MiniApp running time.
My understanding is that the URLs unregistered in backend MiniApp platform (including resource URL, page URL, etc.) are not permitted by MiniApp running time.
Checking the documentation, I think it's the current scenario for Alipay and Baidu MiniApps, yes. This means that the developer must submit manually these requirements.
Platforms may choose to tighten the measures, only allowing the backend-registered trusted domains. However, I still think we should propose a common way to express this dependency to increase the security on any platform. So, the user agent will be aware of the security requirements at any moment.
@QingAn , @Sharonzd, any objection to include a manifest member for the CSP? Could it be helpful for platforms like Baidu and AliPay MiniApps? Any specific reason for including these CSP elements through the platform's developer console (e.g., manual verification)?
As mentioned in w3c/miniapp-packaging#46 and #31, MiniApps user agents are vulnerable to XSS attacks. So we should define a mechanism to enable user agents to restrict the origin of the external resources (i.e., images, stylesheets, media, and other scripts).
About static resources
Most of the MiniApp implementations support external -they are not within the MiniApp package- media resources included in the user interaction components (e.g., Baidu, WeChat, QQ, Quick Apps...), also stylesheets and fonts. In these cases, I haven't found specific limitations in the sources, only constraints related to file formats.
About dynamic resources
Network operations from scripts are different, and some MiniApp versions limit dynamic fetches, downloads, and other networking communications. In most of the cases, they require a safelist of domains in advance (e.g., Baidu, ByteDance, QQ, Weixin). Through different means, developers have to communicate with the platform as a previous step, so this safelist is not included in the configuration manifests. I see a case of a flag in the MiniApp manifest to specify if the external URLs must be checked or not.
"settings": { "urlCheck" : boolean }
.A CSP (Content Security Policy)
With these scenarios, we could consider configuring a CSP and restricting the external domains that could dynamically interact with the MiniApp.
Existing CSP directives would allow us to restrict the source of the HTTP resources
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. So, one solution is to introduce another member in the manifest to control, at least, the safelist of domains for the network operations performed by the scrips.Something like:
It should be optional, but we also should define a policy by default (something like
none
orself
) to block/allow any external source.The text was updated successfully, but these errors were encountered: