XSS is typically broken down into three categories:
Reflected XSS is when an XSS exploit is provided through a URL paramater.
You can see the XSS exploit provided in the data GET parameter. If the application is vulnerable to reflected XSS, the application will take this data parameter value and inject it into the DOM.
<html> <body> <script>alert(1)</script> </body> </html>
Depending on where the exploit gets injected, it may need to be constructed differently.
Also, the exploit payload can change to fit whatever the attacker needs it to do. Whether that is to extract cookies and submit it to an external server, or to simply modify the page to deface it.
One of the deficiencies of reflected XSS however is that it requires the victim to access the vulnerable page from an attacker controlled resource. Notice that if the data paramter, wasn’t provided the exploit wouldn’t work.
In many situations, reflected XSS is detected by the browser because it is very simple for a browser to detect malicous XSS payloads in URLs.
Stored XSS is different from reflected XSS in one key way. In reflected XSS, the exploit is provided through a GET parameter. But in stored XSS, the exploit is provided from the website itself.
Imagine a website that allows users to post comments. If a user can submit an XSS payload as a comment, and then have others view that malicious comment, it would be an example of stored XSS.
The reason being that the web site itself is serving up the XSS payload to other users. This makes it very difficult to detect from the browser’s perspective and no browser is capable of generically preventing stored XSS from exploiting a user.
DOM XSS is XSS that is due to the browser itself injecting an XSS payload into the DOM. While the server itself may properly prevent XSS, it’s possible that the client side scripts may accidentally take a payload and insert it into the DOM and cause the payload to trigger.