There's a webstore that i am trying to find a XSS vulnerability for BUG BOUNTY. On that store is a search bar that i can send anything


But even if i use </title> for trying to break it, the result gets into:

<title>You searched for </title><script>alert(1);</script> - Blabla's Store </title>

it seems the </title> i provided is acting like 'string', why its not able to close the title tag? i mean.. its definetly a closing tag! can anyone explain me what is going on ?

  • 6
    You have simply not found a vulnerability! Commented Oct 16, 2023 at 11:03

1 Answer 1


Assuming the XSS isn't firing, the problem is that you're looking at the processed HTML, not the raw page source. This usually happens if you're using the browser developer tools - rather than the "view page source" feature, or an intercepting proxy - to examine the HTML. You can get the raw HTML from the dev console using the innerHTML property of elements.

For example, if you right-click on your example text in the question and inspect it in the dev tools, it'll look like <title>You searched for </title><script>alert(1);</script> - Blabla's Store </title>. However, if you use the developer console to request document.body.innerHTML.match(/<code>.*?alert.*?<\/code>/) - which runs a regular expression match on the HTML of the body of this page, selecting the first element that starts with <code>, contains alert, and ends with </code> (<code> being how StackExchange markdown renders content within ` characters) - you'll get instead "<code>&lt;title&gt;You searched for &lt;/title&gt;&lt;script&gt;alert(1);&lt;/script&gt; - Blabla's Store &lt;/title&gt;</code>".

The innerHTML property has shown that, even though the dev tools inspector makes it look like the page contains a <script> substring, the angle brackets were escaped and it actually only contains &lt;script&gt; and similar. If you run the same query on your actual target site - using document.head.innerHTML.match(/<title>.*<\/title>/) since you're instead grabbing the full title of the page from its header - you'll probably see the same escaping on your injected text.

The site is either encoding the < characters as &lt; on the server, or is using the innerText/textContent property rather than the innerHTML property to set the title in Javascript. innerText and textContent automatically encode HTML metacharacters such as <. In other words, this insertion point is not vulnerable. There might be XSS elsewhere on the site, but the title appears to be reflecting user input in a safe way.

You must log in to answer this question.

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