A web content origin is the combination of the protocol, hostname and port of a URL. We say that two URLs are of the same origin if all 3 parts match. For example, https://test.com:443/hello and https://test.com:443/world are the same origin.
Note: when one origin reads/writes to another different origin, we call this interaction cross-origin.
One common example used to explain how this is achieved is when a website lets you input a search query in the URL and then renders your search query in the DOM itself. For example, it might look like this:
If the query value gets directly rendered without any validation, then we’re able to put in whatever HTML we want and have that be rendered. The most traditional thing to try is to try to put in a
<script>alert(1)</script> into the URL, like:
https://vulnerable.com?query=<script>alert(1)</script> . Note that you would need to encode the URL to produce something like:
Then, you can distribute this URL to unsuspecting users (commonly through legit-looking emails), and then when the link is clicked, their browser will execute your malicious code which could do anything from displaying a harmless alert or attaching their cookies and sending it to a web server you control.
The classic example used to explain how stored XSS is achieved is when websites let you make comments.
In this example, as an attacker, you could send in a
<script>alert(1)</script> as the comment body which gets stored in the application’s database. Then, when other users visit the page where your comment is fetched and put into the HTML response, your malicious code will run in their browser!
[onload](https://developer.mozilla.org/en-US/docs/Web/API/GlobalEventHandlers/onload) on regular HTML elements like
svg , etc.
The main defense against XSS is to sanitise user input on arrival. Often, the best way to do this is via tried and tested input sanitising libraries like DOMPurify.