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 upon www.example.com to serve up correct and non-malicious code. If attackers can compromise www.example.com, then they can alter the contents of fancyWidget.js to subvert the security of the site. They could, for example, add code to fancyWidget.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:

1. 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.
2. 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.