Cross Site Scripting is a popular attack technique on the Internet in which malicious code is executed either on the server side or client side, in order to steal sensitive data or digital identities. Together with SQL injections, cross-site scripting also called XSS or even general HTML injections, it constitutes the most commonly used attack technique on web applications and websites. 
Cross Site Scripting attacks presuppose that
a) a hacker or attacker sends a modified hyperlink to a recipient (user or server)
b) The recipient opens it by clicking it or processes it because it is not verified
d) Or the server on which the recipient originally wanted to surf uses web applications that issue dynamic websites and the data doesn’t get checked.
A cross-site scripting attack takes place in the course of accessing websites. If a user visits a website to enter login information, the browser sends a form with data to the server. The server grants access to the website, if the data is correct. A cross-site scripting attack takes place exactly between the these two websites and the sites don’t have to be different sites with different URLs, rather, the attack technique is used for dynamically generated sites to get between client and server while data is being entered. Answers from the server get imitated to send the data entered by the user to an address, which the attacker determines.
This is done by running scripts that the attacker has interposed. These scripts use parameters such as GET, POST and (document.cookie) to subvert communication between client and server. Both in the markup language HTML and in the PHP programming language such methods are supported. Since millions of sites use these languages, XSS attacks are effective means to gain access to user data.
Cross Site Scripting is divided into three types of attacks: 
1.) Persistent: With persistent XSS attacks, malicious code remains on the display and the user is not necessarily identifiable. In forums, communities or guestbooks of sites, malicious code is unfiltered and presented in the form of links since such sites often check your entries. A persistent XSS attack can take place in the cache of a web application or in a connected database of such websites. Persistent attacks are always on the server side and have large potential risk.
2.) Non-persistent: Here, the user is sent a manipulated link. Once the link is clicked, the malicious code will launch and run a script. Often fake emails from attackers are sent to prompt users to interact. Attackers mimic forms and websites and insert a script to reach session cookies with user data. The risk potential associated with non-persistent XSS attacks is relatively low, because they require a high degree of user interaction. They are always on the client side and are usually used in conjunction with dynamic websites.
3.) Local: In this case, the malicious code will be sent directly to a client to execute it, for example, in the browser. A local XSS attack is always directly executable malicious code that does not depend on a vulnerability in the server-client communication. Rather, it is a direct attack in the form of a script that asks certain information, such as URL arguments or script tags. After the interrogation, the malicious code runs in the background without the user’s knowledge. Local XSS attacks aim to attack static HTML pages but they are also dependent on a user who clicks on a malicious link.
Cross Site Scripting is also used in the field of search engine optimization. A website is hacked to place backlinks on it that point to a domain to be strengthened. Cross site scripting is a known black-hat method, which exploits the vulnerabilities of servers and clients in order to embed links that webmaster of the affected website are not supposed to know about. Google and other search engines punish such links because they are regarded as manual, unnatural measures. Search engines often cannot find where these links originated from or how they came to the site. In order to prevent cross-site scripting effectively, the webmaster has to take various measures which have been described above.