Cross-Site Scripting (XSS) is a widespread web vulnerability that occurs when an application fails to properly sanitize user input. This allows attackers to inject malicious JavaScript into a webpage, which is then unknowingly executed by other users who visit that page.
| Type | Description |
|---|---|
Stored (Persistent) XSS |
The most critical type of XSS, which occurs when user input is stored on the back-end database and then displayed upon retrieval (e.g., posts or comments) |
Reflected (Non-Persistent) XSS |
Occurs when user input is displayed on the page after being processed by the backend server, but without being stored (e.g., search result or error message) |
DOM-based XSS |
Another Non-Persistent XSS type that occurs when user input is directly shown in the browser and is completely processed on the client-side, without reaching the back-end server (e.g., through client-side HTTP parameters or anchor tags) |
XSS Payload- <script>alert(window.origin)</script> , <script>print()</script>
Tip: Many modern web applications utilize cross-domain IFrames to handle user input, so that even if the web form is vulnerable to XSS, it would not be a vulnerability on the main web application. This is why we are showing the value of window.origin in the alert box, instead of a static value like 1. In this case, the alert box would reveal the URL it is being executed on, and will confirm which form is the vulnerable one, in case an IFrame was being used.
As some modern browsers may block the alert() JavaScript function in specific locations, it may be handy to know a few other basic XSS payloads to verify the existence of XSS. One such XSS payload is <plaintext>, which will stop rendering the HTML code that comes after it and display it as plaintext. Another easy-to-spot payload is <script>print()</script> that will pop up the browser print dialog, which is unlikely to be blocked by any browsers. Try using these payloads to see how each works. You may use the reset button to remove any current payloads.