I have a XSS case that I would like to exploit as a proof of concept, however the payload seems to only be triggering when pasted in and not from the URL.

Basically, I have a search box which when pasting in the following XSS payloads triggers an alert.

<img src=x onerror=alert(1)>
<noscript><p title="</noscript><img src=x onerror=alert(1)>">

However, when clicking the search button and sending the GET request to /search?query=<payload> the payload doesn't seem to be triggering.

Does anyone have any idea why or how I could get it to reflect from the URL? It seems quite weird that it only works immediately when pasted in but not after submitted.


The following snippet is from the search results page source. The search term - aka payload in this scenario - is displayed as normal without any sanitizing but it is not executed.

  • Which browser are you using? Sep 8, 2021 at 13:23
  • 1
    This is not surprising at all ... your browser is URL encoding it ...
    – schroeder
    Sep 8, 2021 at 13:59
  • This probably occurs because the on-page Javascript that updates the page when you type in a search term fails to sanitise the input. When you do the same thing through the URL, the input is handled differently, so you get a different result.
    – Polynomial
    Sep 8, 2021 at 14:43
  • @Polynomial Do you think this could be exploited in any way? In the search results page, after the request is handled, the XSS payload is displayed as is, (and also part of the DOM tree), however nothing is executed.
    – Legolas
    Sep 8, 2021 at 14:52
  • @BenoitEsnard Using Chromium browsers
    – Legolas
    Sep 8, 2021 at 14:54

1 Answer 1


There are two possible cases I can see for this:

  1. This is due to the browser URL-encoding the exploit strong, and the server isn't decoding it. That might be defeated in various ways (try other browsers, try submitting the navigation request via JS or via a hardcoded link rather than using the in-app button, try finding an exploit string that doesn't require any characters that get encoded, etc.).
  2. The actual vulnerability is only DOM-based XSS based on user input on the page; the vulnerable code is not parsing text from the URL or server, at least not in a vulnerable way. In that case, you probably can't exploit it except for self-XSS, but it's worth looking closely at the code in question to see what's going on. There might be a vector to hit the vulnerable code path from elsewhere, or there might be a vulnerable code path in the handling of the reflected code (or URL, if relevant) that your current exploit string doesn't hit but another would.

Bear in mind that what you're seeing in the browser dev tools (in your screenshot) IS NOT THE RAW SOURCE CODE that the browser is parsing. It is pre-parsed code that includes, among other things, decoding HTML entities (but still treating them as text). You can tell it's pre-parsed because it's doing syntax highlighting and code folding. If you double-click on that h1 to edit its inner HTML, or get the innerHTML property from script, you'll see that the < characters are HTML-encoded. If you want to actually view the source code, you should either look at the raw response in the Network tab, use an intercepting proxy to view the raw source there, ... or just actually use the browser's View Source feature (rather than the Inspect / dev tools feature).

You must log in to answer this question.

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