I'm working through all issues that the static security analysis tool Fortify found in our internal Angular application. There is one particular issue I'm not confident of how to work with. Please see the following code, which is the event handler of a <select> HTML element:

if (selectedValue === -3) {
        window.location.href.substring(0, window.location.href.indexOf('/ui/')) + '/ui/newEntry',

In case the selected value is -3 (Add new element), a new tab/window will be opened where the user can create a new entry.

The script is executed under https://my.domain.com/hello/world/ui/account/123.

I assume that Fortify marks this code as prone to XSS attacks because of constructing the destination URL from the current URL, which might be evil.

Now I'd like to learn how to solve this potential problem. Can I somehow safely construct the URL to open?

  • This page describes the risks: cheatsheetseries.owasp.org/cheatsheets/…
    – pcalkins
    Jun 1 at 17:46
  • Make sure you explicitly set the URL. You can persist/pass along some value then case/switch accordingly. The important bit is to be in full control of what URL you are setting there. Otherwise a malicious link can be crafted that comes from your domain.
    – pcalkins
    Jun 1 at 18:02

1 Answer 1


I think the XSS flag is coming from the fact that window.location.href could be overwritten and include a javascript-URI for instance.

If you want to keep using window.location.href in the construction of a new URL, you could add extra validation for the current value (e.g., does it start with exactly https://example.com/ui/. I would not be surprised if the flag remained, however, for as long as you construct the URL this way.

Safer alternatives would just using a fixed relative path (e.g. window.open('/ui/newEntry', '_blank')).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.