Cross-site scripting (XSS for short) is a widespread vulnerability affecting many web applications. It allows an attacker to inject malicious code to a website in such a way that the browser of the user visiting the site will execute this code.
Usually, to exploit such a vulnerability, some interaction with the user is required: either the user is lured to the infected site using social engineering, or just wait until he visits this site. Therefore, developers often do not take XSS vulnerabilities seriously.
But if they are not eliminated, this can pose a serious security risk.
Imagine that we are in the WordPress admin panel, we add new content. If we use an XSS-vulnerable plugin to do this, it can force the browser to create a new administrator, modify content, and perform other malicious actions. Cross-site scripting gives an attacker almost complete control over the most important software these days it's a browser.
XSS: Injection Vulnerability
Any website or application has multiple data entry points - form fields up to the URL itself. The simplest example of input is when we enter a username and password into a form:
Our name will be stored in the site database for subsequent interaction with us. Surely, when you were authorized on any site, you saw a personal greeting in the style of "Welcome, Ilya."
It is for such purposes that usernames are stored in the database.
An injection is a procedure when a special sequence of characters is entered instead of a name or password, forcing the server or browser to respond in a certain way that the attacker needs.
Cross-site scripting is an injection that injects code that will perform actions in the browser on behalf of a website. This can happen both with the notification of the user, and in the background, without his knowledge. 
Traditional XSS attacks:
Reflected (non-permanent).
A reflected XSS attack is triggered when a user clicks on a specially crafted link.
These vulnerabilities occur when data provided by a web client, most commonly in HTTP request parameters or HTML form, are executed directly by server-side scripts to parse and display the results page for that client, without proper processing.
Stored (permanent).
Stored XSS is possible when an attacker manages to inject malicious code into a server that executes in the browser each time the original page is accessed. A classic example of this vulnerability is forums that allow comments in HTML format.
Vulnerabilities caused by client-side code (JavaScript, Visual Basic, Flash, etc.):
Also known as DOM models:
Reflected (non-permanent).
The same as in the case of the server side, only in this case the attack is possible due to the fact that the code is processed by the browser.
Stored (permanent).
Similar to stored XSS on the server side, only in this case the malicious component is stored on the client side using browser storage.
Examples of XSS vulnerabilities.
Interestingly, in most cases where this vulnerability is described, we are scared with the following code:
http://www.site.com/page.php?var=
There are two types of XSS vulnerabilities - passive and active.
Active Vulnerability is more dangerous, since the attacker does not need to lure the victim through a special link, he just needs to inject the code into the database or some file on the server. Thus, all site visitors automatically become victims. It can be integrated, for example, using SQL injection (SQL Injection). Therefore, you should not trust the data stored in the database, even if they were processed during insertion.
Example passive vulnerability can be found at the very beginning of the article. Social engineering is already needed here, for example, an important letter from the site administration with a request to check your account settings after restoring from a backup. Accordingly, you need to know the address of the victim or just arrange a spam mailing list or post on some forum, and it’s not even a fact that the victims will be naive and follow your link.
Moreover, both POST and GET parameters can be subject to passive vulnerability. With POST parameters, of course, you have to go for tricks. For example, a redirect from an attacker's site.