Best option to store hardcoded domain names in web application
First, you could host the files on your own server and use relative paths.
If not viable, you will need some system to change the URLs for these dependencies dynamically, you could source them from environment variables, or a config file? The DB is not a bad source for that.
If you're going to include files from a CDN you should make use of subresource integrity to ensure the file is not loaded if it has been modified.
I suspect SCA will still flag those being on an external domain though, in which case, you can audit the vulnerabilities if you're not going to change from this approach.
When addressing security warnings by tools like Fortify, it's important to understand the reasoning behind the warnings so you can mitigate them correctly.
Hardcoded Domain in HTML warning
Fortify's reasoning for this "Hardcoded Domain in HTML" warning is linking to an external domain will compromise the security of your site because the file you are linking can be changed. The following is from "Fortify Taxonomy: Software Security Errors":
Abstract
Including a script from another domain means that the security of this web page is dependent on the security of the other domain.
Explanation
Including executable content from another web site is a risky proposition. It ties the security of your site to the security of the other site.
Example: Consider the following
<script>
tag.<script src="http://www.example.com/js/fancyWidget.js"/>
If this tag appears on a web site other than
www.example.com
, then the site is dependent uponwww.example.com
to serve up correct and non-malicious code. If attackers can compromisewww.example.com
, then they can alter the contents offancyWidget.js
to subvert the security of the site. They could, for example, add code tofancyWidget.js
to steal a user's confidential data.
- Ref: https://vulncat.hpefod.com/en/detail?id=desc.content.html.hardcoded_domain
Attack Mitigation
There are two ways to address this:
- Move all scripts to your own domain. This way you are in control of the content of the scripts. This seems to be Fortify's recommendation.
- Use the Subresource Integrity property for
<script>
and<link>
tags as described by the Mozilla Foundation (MDN) below. This will also prevent browsers from executing remote scripts that have been modified.
Subresource Integrity (SRI) is a security feature that enables browsers to verify that files they fetch (for example, from a CDN) are delivered without unexpected manipulation. It works by allowing you to provide a cryptographic hash that a fetched file must match.
An example of the SRI integrity
attribute is shown below and used by many CDNs.
<script src="https://example.com/example-framework.js"
integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
crossorigin="anonymous"></script>
Ideally, Fortify should support SRI as a valid mitigation technique, but if they don't, they will still flag these errors and you would need to manually check and give passes to any such warning that has been mitigated.
- Ref: https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity
Best Option
The "Best" option depends on your requirements. Here are some thoughts:
- If you are running a commercial service and need your site to be operational and under your control, serving the files yourself may be the best option since you can control not only the security but also availability. Regarding availability, if you are using a remote site and the remote site becomes unavailable, then your site may no longer work properly. Even if you host the files yourself, you should still use SRI just in case your own files are compromised.
- If you are running a non-commercial or small commercial site, it may be okay to use a CDN with SRI as it would allow you to enforce security while not requiring you to host the files. The downside is that if the changes or disappears, your site may not work.