What is Cross-Site Scripting?
Who should be concerned about XSS?
Websites that accept user input without validation can become vulnerable to cross-site scripting.
Types of XSS
There are three types of Cross-Site Scripting based on where the hacker or attacker injects the code.
Here malicious links are hidden to trick users into sending harmful scripts as requests to the server. It will generally be appended as part of a seemingly usual request to the server from the client. Say, for instance, the address field in a form. If proper validation is not used while checking the user-provided data in HTML, the malicious script is sent unwittingly as part of the response. Once the victim’s client loads the server response, the malicious script automatically loads and runs on the client-side.
This type of Cross-Site Scripting is called Reflected or non-persistent XSS because it has to be reflected by the client from the server-side every time.
As the name indicates, the script is loaded on the server-side. Unless the developer processes the display content through proper validation, any user accessing that part of the application will execute the malicious script.
Stored XSS is also called Persistent Cross-site scripting. Once injected into the application, the malicious script will affect all clients accessing that part of the application.
Sites that store data on the client-side using Document Object Model (DOM) are vulnerable to DOM-based XSS. Here, the malicious script is injected into the DOM on the client-side, so it becomes more difficult to detect it.
While Reflected and Stored XSS are server-side attacks, DOM-based is a client-side issue.
It is possible to eliminate all XSS vulnerabilities by sanitizing the user input at the framework level/stage.