Hard Coded Domain Vulnerability

The documentation https://wtw-im.github.io/es-components/#section-themes specifies links to dependent stylesheets. The links do not have SRI https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity on them and therefore linking introduces a html5 vulnerability that is well documented at https://vulncat.fortify.com/en/detail?id=desc.content.html.hardcoded_domain .

The following links introduce the vulnerability since https://bdaim-webexcdn-p.azureedge.net is a different domain and consuming applications security would then rely on the security at https://bdaim-webexcdn-p.azureedge.net as well.

        <link rel="stylesheet" href="https://bdaim-webexcdn-p.azureedge.net/es-assets/source-sans-pro.css" />
        <link rel="stylesheet" href="https://bdaim-webexcdn-p.azureedge.net/es-assets/icons.css" />

A possible solution is to ship the styles in the es-components npm package perhaps in a folder called styles. Or add SRI to the links.

For now, since we use Checkmarx, we plan to place the downloaded files on our server and serve them to our application in our domain. We expect there to be possible issues keeping up with this solution when we update es-components or any of the assets change. Another solution we entertained was to make the vulnerabilities as Not Exploitable in Checkmarx but without the links having SRI that seams erroneous.