A web page shows an error login page using these javascript lines

    let queryParams = new URLSearchParams(window.location.search);
    document.getElementById("message").innerText = queryParams.get("message");
    let link = document.getElementById("link");
    link.innerText = queryParams.get("linkText");
    link.href = queryParams.get("linkUrl");

The last javascript line allows me to hide javascript inside a link in the web page crafting an url like the following.


1) the user click the shortened version of this link

2) the user click "click here to shine"

3) the alert opens

I was inspired by this article on portswigger https://portswigger.net/web-security/cross-site-scripting/dom-based
in particular from this example

If a JavaScript library such as jQuery is being used, look out for sinks that can alter DOM elements on the page. For instance, the attr() function in jQuery can change attributes on DOM elements. If data is read from a user-controlled source like the URL and then passed to the attr() function, then it may be possible to manipulate the value sent to cause XSS. For example, here we have some JavaScript that changes an anchor element's href attribute using data from the URL:

$(function(){ $('#backLink').attr("href",(new URLSearchParams(window.location.search)).get('returnUrl')); });

You can exploit this by modifying the URL so that the location.search source contains a malicious JavaScript URL. After the page's JavaScript applies this malicious URL to the back link's href, clicking on the back link will execute it:


QUESTION: to me they look the same kind of attack but someone told me it is a self-XSS. Anyway I read that self-XSS expects the user to self-paste javascript code in his console. So I'm confused and I'd like to know which type it is. Also, can be considered a vulnerability of medium/high severity or not?

1 Answer 1


I would call it a DOM-based (reflected aka non-persistent) XSS requiring user interaction.

It's not self-XSS, because self-XSS is just a way to call a specific type of attack where the user actually injects the code themself, typically by copying and pasting the malicious code directly into their browser JS console. Self-XSS is actually a social engineering attack, rather than a real XSS vulnerability. Apparently in the past self-XSS could also be achieved by tricking a victim into running malicious code in the address bar, like javascript:somethingMalicious(); but that's not possible anymore in some browsers (I just tested it in Chrome, it doesn't work). However links like <a href="javascript:alert();"></a> still work when you click on them.

The severity of your vulnerability depends on several factors, and you might want to consider CVSS to try to estimate it, although I'm not really a fan of those scoring systems. With CVSS version 3.1 and these parameters ( AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N ) you would get a score of 4.3, for example. Note that I don't know anything about the details of your vulnerability, and that I just supposed the attack complexity was low, user interaction was of course required, confidentiality impact was low, and no impact on integrity or availability. If you set the confidentiality impact to high, and attack complexity to high, you will get a score of 5.3, for example. Only you can know if those numbers are meaningful or not. Sometimes it can be very difficult to estimate the attack complexity and the impact of user interaction.

  • <a href="javascript:alert();"></a>, does not work anymore in modern browser. Jun 11, 2023 at 18:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .