Having said that, the two most common attack vectors are:
Reflected XSS attacks operate on the principle of “temporary” data — this might not seem intuitive at first but an example could be the following:
(there is no actual vulnerability, but if it did exist, the page would need to print a user's input for the video URL)
As seen in the exampe above, such attacks are quite primitive — they require little-to-no effort on the part of an attacker, are hard to trace and often mislead even tech-savvy users. You might not think twice about clicking on a “trusted” website such as Google, YouTube, or et cetera: this is why such an attack is so effective, particularly when sent through messaging platforms where links are often trimmed.
For example, the “biography” field of a blog website that fails to remove JS or special characters might be vulnerable to a simple snippet of code like:
On the vulnerable website, loading your “biography” will display the alert (message: “XSS!”).
While there are other forms of XSS attacks, the two most common include “reflected” and “stored” XSS attacks. Attacks can run after a victim visits a compromised (user inputs being parsed in ‘raw’ without any sanitizing) page or clicks on a seemingly trustworthy link (with JS embedded into, say, the query parameter). Regardless of what an attacker does, it is important for users to avoid clicking on content that they do not trust. It is a shared responsibility; a “zero-trust” approach to user input should be taken with any secure web application.
XSS stands for Cross Site Scripting.