
BMcKeever981950 (Community Member) asked a question.
I have seen the answers on these forums that explain why Veracode flags javascript like `window.location.href = url;` as a potential XSS problem under CWE-80. The example that I've seen cited is that url could begin with "javascript:" and therefore execute code. Is that the limit of the potential threats, or are there other examples that don't match that? In particular, if my code is more like `window.location.href = "ShowItem.aspx?id=" + id;`, is there a vulnerability here?
Is `encodeURIComponent` the recommended mitigation? Are there other accepted ones?
.png)
Hi @BMcKeever981950 (Community Member) ,
Veracode Static Analysis does not currently automatically analyze this beyond "dynamic String data goes into window.location". For things like an id you may wish to turn it into a Number which will guarantee to Veracode Static Analysis that an attacker will be unable to use that data.
Alternatively, for dynamic data where there is little variance you could consider using an allow-list like so: https://community.veracode.com/s/article/Using-an-Allow-list-in-a-Way-Static-Analysis-can-Detect .
If the id is alphanumeric and dynamic then `encodeURIComponent` is the best strategy for ensuring any dynamic data will not be interpreted as control characters in the URL.
Unfortunately, Veracode Static Analysis does not automatically do any inspection of where and how the dynamic data is added and does not accept `encodeURIComponent` as a cleansing method (for example it would not be valid when used on hostnames or protocols) so you will likely still need to document this in a mitigation proposal and have that manually reviewed by someone in your organization.
You can learn more about this process here: https://community.veracode.com/s/knowledgeitem/mitigations-part-1-what-is-a-mitigation-MCKTIDIWZQ3RBENLRUYP4KSZW3SQ .
Thank you,
Boy Baukema