I am a software engineer and have been watching a lot of videos about XSS.

But I fail to understand how is it dangerous if it runs on the client side and does not execute on the server side which contains the databases, and many important files.

  • Comments are not for extended discussion; this conversation has been moved to chat.
    – Rory Alsop
    Commented Apr 5, 2019 at 8:07

11 Answers 11


Below are the things an attacker can do if there is XSS vulnerability.

  • Ad-Jacking - If you manage to get stored XSS on a website, just inject your ads in it to make money ;)
  • Click-Jacking - You can create a hidden overlay on a page to hijack clicks of the victim to perform malicious actions.
  • Session Hijacking - HTTP cookies can be accessed by JavaScript if the HTTP ONLY flag is not present in the cookies.

  • Content Spoofing - JavaScript has full access to client side code of a web app and hence you can use it show/modify desired content.

  • Credential Harvesting - The most fun part. You can use a fancy popup to harvest credentials. WiFi firmware has been updated, re-enter your credentials to authenticate.

  • Forced Downloads - So the victim isn’t downloading your malicious flash player from absolutely-safe.com? Don’t worry, you will have more luck trying to force a download from the trusted website your victim is visiting.

  • Crypto Mining - Yes, you can use the victim’s CPU to mine some bitcoin for you!

  • Bypassing CSRF protection - You can make POST requests with JavaScript, you can collect and submit a CSRF token with JavaScript, what else do you need?

  • Keylogging - You know what this is.

  • Recording Audio - It requires authorization from the user but you access victim’s microphone. Thanks to HTML5 and JavaScript.

  • Taking pictures - It requires authorization from the user but you access victim’s webcam. Thanks to HTML5 and JavaScript.

  • Geo-location - It requires authorization from the user but you access victim’s Geo-location. Thanks to HTML5 and JavaScript. Works better with devices with GPS.

  • Stealing HTML5 web storage data - HTML5 introduced a new feature, web storage. Now a website can store data in the browser for later use and of course, JavaScript can access that storage via window.localStorage() and window.webStorage() Browser & System

  • Fingerprinting - JavaScript makes it a piece of cake to find your browser name, version, installed plugins and their versions, your operating system, architecture, system time, language and screen resolution.

  • Network Scanning - Victim’s browser can be abused to scan ports and hosts with JavaScript.

  • Crashing Browsers - Yes! You can crash browser with flooding them with….stuff.

  • Stealing Information - Grab information from the webpage and send it to your server. Simple!

  • Redirecting - You can use javascript to redirect users to a webpage of your choice.

  • Tabnapping - Just a fancy version of redirection. For example, if no keyboard or mouse events have been received for more than a minute, it could mean that the user is afk and you can sneakily replace the current webpage with a fake one.

  • Capturing Screenshots - Thanks to HTML5 again, now you can take screenshot of a webpage. Blind XSS detection tools have been doing this before it was cool.

  • Perform Actions - You are controlling the browser,

  • 1
    So I have one question.. Let's say a web app had an xss vulnerability, and someone had used this to exploit some other user by running some malicious js code. Let's say this code key logs and sends the key strokes to another website by making a request. Now will this malicious js code keep running as long as the browser is open or will it keep running as long as the vulnerable tab within the browser is open?
    – Sai Kumar
    Commented Apr 1, 2019 at 17:08
  • 2
    It still depends on how the attacker program's it. basically depending on user events or triggering the code on specific time intervals.
    – Gowtham
    Commented Apr 1, 2019 at 17:12
  • 13
    @SaiKumar In general, an XSS vulnerability can do anything with the client you as a website administrator can do with the client.
    – Philipp
    Commented Apr 2, 2019 at 8:31
  • 3
    For the points with "requires authorization" - it must be noted that if the user already gave that permission to the webpage, you have free rein and don't need to ask. Commented Apr 2, 2019 at 10:19
  • 3
    It's worth mentioning for the entries labeled "it requires authorization from the user" - the user is likely to authorize because it's a site they trust, and the XSS on that site gets it for free if that site is already authorized. Edit: someone else already partly said this, sorry Commented Apr 2, 2019 at 23:53

Maybe a real life example would help to understand how dangerous an apparently minor security flaw like XSS can be.

As part of a security assessment, my company was tasked with trying to access the CEO's personal emails. I managed to learn their personal email address through some OSint. Now one could go for a spear phishing with a custom version of one of the many info-stealer malware, but I prolonged the information gathering phase a little longer.

It turned out the CEO loved boats and they were selling one of theirs on a boat-selling site. The site seemed pretty amateur; I registered and fooled around a bit. And what did I find? The site lets you manage your password by prefilling a password field with the current one. Spurred on by this, I investigate the site a little bit more. I came across a stored XSS vulnerability: when you answer an offer, you can put arbitrary HTML code—including scripting—in it, and it will be executed in the visitor's browser!

Seem pretty "innocuous," doesn't it? What if you combine it with the bad password management?

So I crafted a script that fetched the password page (it's an intra-domain request, SOP is satisfied), extracted the password and the client information (UA, OS and similar), and sent it to a C&C of mine. Then I instilled a sense of urgency in the CEO by carefully writing an email informing them about my "intention" to buy.

After a day, I received the password they used to log in the boat site. As expected, it was the same password used for their email. (There was no 2FA; I can't remember if it was a thing yet.) With that, I was able to access the webmail (the client information was used to simulate a legitimate access, in case it was necessary to keep a low profile).

Long story short: an attack is not a single atomic step, it's made of little conquers. If you give your adversary room for a step, you'll never know what they can do from there. An XSS is room for the attacker, as you have seen quite a bit of it.


Attacker-controlled code, which runs within the context of the web application on the client side, has full control over what the client does and can also read the DOM of the HTML page, etc.

This means it can both steal secrets which are inside this page (passwords, etc.) and also do things as logged in client (like buy something, send bomb threats in a mail client, etc.). Note that this kind of activity can often be hidden from the client so that he/she does not realize that he/she is currently attacked.


An XSS attack is not a danger to the server. It's a danger to the reason you have a server. Not in a technical sense but very much a human one, as any kind of XSS attack originating from your site usually ends with your reputation down the toilet. A few test cases:

  • Someone redirects from your site to a fake login page. Now you have a potential mass security breach of user accounts on your site.
  • Someone puts a cryptominer on your site. This will make your visitors' machines work overtime and when spotted, makes you look either grossly greedy and/or grossly incompetent as a sysadmin. Neither of which is a good look.
  • Someone redirects traffic from your site to a competitor. I shouldn't have to explain why this is bad.
  • Someone puts some javascript in there that makes your site unusable or even crash browsers. Again, should be obvious why this is bad.
  • Someone puts DDOS code in your site to try take down your site or a third party. If aimed at you, should be obvious why this is bad. If aimed at someone else and your site is deemed culpable, your hosting provider can cut you off if you do not fix your site for breach of contract.
  • Someone replaces your ads with their own. If you rely on ad revenue, they're stealing that revenue.
  • Someone uses it to snoop on your users. Hel-lo, breach of GDPR.

When XSS was first becoming widely known in the web application security community, some professional penetration testers were inclined to regard XSS as a “lame” vulnerability

source: Web Application Hackers Handbook

XSS is a command injection of the client side, like the other user pointed out, it can result in any action that can be performed by the user. Mostly XSS is used for session hijacking where the attacker using javascript makes the victim transmit session cookies to an attacker-controlled server and from there the attacker can perform "session riding".

But XSS can also result in complete application takeover. Consider a scenario in which you inject javascript and it gets stored. The admin then loads that into a web browser (usually logs or CMS). If an XSS is present there you now have the admin session tokens. That is why XSS can be very dangerous.

  • 1
    Not just stored XSS but what if you send a malicious URL to the admin? The same threat applies.
    – schroeder
    Commented Apr 1, 2019 at 9:38
  • Absolutely.I didnt write it because i only wanted to add what steffen wrote.
    – yeah_well
    Commented Apr 1, 2019 at 18:19

Most of the possible consequences of XSS vulnerabilities affect the user, not your server. So if you don't care about your user getting their accounts on your website compromised or your users seeing content on your website which doesn't come from your server, sure, ignore those vulnerabilities.

But if your users have admin rights, then an XSS vulnerability can easily lead to unintentional admin actions. A classic case of that is a log viewer in your admin area which isn't XSS-proof. Some javascript snippets in your access logs might get executed by your admins and perform administrative actions under their account. This is why you sometimes see javascript snippets in the HTTP headers of the bots which try to hack your website.


To give you a real life example where XSS was used to directly take over the server in an incident about 10 years ago (although I have forgotten the name of the (small/unimportant) website and I doubt it exists anymore):

Report to webmaster: "There is XSS vulnerability on your website. You should fix this. How should I send you the details?"

Answer of the wannabe webmaster: "Show me how you would misuse this. My server is super secure! Try it if you want but you will have no chance."

Answer of the reporter: "Then take a look at my profile page on your website."

The webmaster did this and suddenly the whole website was dead. What happened? The reporter used a XSS vulnerability to insert JavaScript code on his profile page.

The JavaScript code (running in the browser and session of the webmaster) sent requests to the server to:

  1. add a new account with with highest rights (for demonstration purposes)
  2. to rename PHP-files and SQL-tables on the server (the website had a administration section which allowed this for administration purposes like updates or installing widgets similar to many CMS-systems)

Additional damage could have been done by sending a request to the hosting company to cancel the subscription of the server and of the domain and transfer money from his banking account (provided the webmaster was logged in the hoster/domain registrar/bank and they had no CSRF-protection which wasn't that uncommon 10 years ago).

Also don't forget XSS-worms like the MySpace-worm Samy that spread over all profile pages and might DDOS your server or harm your users.

  • Thank you. I now clearly understood how can xss be used to break a website. But how do you rename the php files and sql tables on the server? can javascript be used to rename a file sitting on the server? and what if the file was not within the same directory as the webpage? and can we run sql queries using javascript?
    – Sai Kumar
    Commented Apr 3, 2019 at 3:53
  • The Website had a web administration tool similar to phpMyAdmin which allows editing SQL tables and PHP files with a web gui instead of needing SSH or similar. The JavaScript sent a request similar as the one that tool would do. What files are in danger depends on the capabilities, security and permissions of the administration tool.
    – H. Idden
    Commented Apr 3, 2019 at 7:06

It looks like you're looking for danger to the server (including SQL etc.), not the client, so many dangers don't apply.

But there is a danger to the server from what the client is allowed to do on the server. If the client has permission to change the database, so can an attacker. And the same goes for anything a client has permission to do on the server.


XSS itself is dangerous in following sense:

  • Session ID/ cookie can be theft to gain full access to victim accounts.
  • Temporary Defacement of the website. Running malicious JS scripts (miner, card data stealer, key-logger etc)
  • Using exploitation frameworks like Beef an attacker can do some OS calls such as opening webcams remotely, turning microphone, redirect all websites to malicious websites etc.
  • Sometimes XSS can be used to steal victims secret tokens, CSRF (cross site request forgery) tokens, API keys and then further exploitation can be done such as CSRF attacks.

This blog and this one show how XSS attack is used to perform SQL injection in a web application.


You have from other answers a very good list of technical reasons why XSS is a problem. I will give another perspective.

XSS is a vulnerability which is quite easy to bring into your code, and is discoverable by scanners. This is probably one of the reasons why it is relatively well known to the "general public", including journalists (in the sense of "I heard about that").

If you have one publicly available, it may then be described as

Sai Kumar LLC has an extremely vulnerable site, because it has an XSS. XSS is a Very Dangerous Vulnerability. Very. It is.

It allows all your data to be stolen. It does. The͟ ̨da҉t͘a̵ ͢haś ̴al͞r̀ead́y ͠b̷e̷e̶n̨ s͝t͜o̢l͝e͜n. Įt̨ ̷ha̵s.

You can then do all kind of belly dancing explaining that it is not the vulnerability, the erratum will be posted in font 3 pt on page 74, grayed out.

This is why I systematically raise the CVSS of XSS findings on my public web sites (when they are revealed by a pentest, scan or other tests).


Stored cross-site scripting is very risky for a range of reasons: The payload is no longer visible for the browser's XSS filter. Users may by chance trigger the payload if they go to the affected page, whilst a crafted url or precise form inputs would be required for exploiting reflected XSS.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .