Cross-Site Scripting is one of the most common web application vulnerabilities posing threat to around 65% of all websites globally. A typical attack involves delivering malicious content to users in a bid to steal data or credentials.

Also known as XSS or CSS, Cross-Site Scripting is prevalent largely due to the inherent weaknesses client-side scripting languages like JavaScript and HTML, making it almost impossible for application developers to get rid of them completely.

While it’s comparatively easier to patch this kind of vulnerability with certain data validation logics and encoding outputs, most website owners do not even know about XSS vulnerability and how it could be harming their end users.

PART 1: What is XSS

According to the Open Web Application Security Project


In simpler words, such a vulnerability allows web application to echo malicious inputs that are executed back into the user’s browser. A successful attack leads to stealing information, session hijacking, malware, sensitive information leakage, and display of malicious advertisements.

PART 2: Types of Cross Site Scripting

There are many ways in which attackers can spot, plant, and exploit vulnerability within the web applications. Here are few of the most common techniques or types.

1.      Reflective XSS

This kind of attack is initiated by luring users to click on a link that launches cross-site scripting attack. Often malicious emails are sent from fake addresses and ask users to click on a link for specific information or news. If the user clicks on it, malicious JavaScript content is reflected back to user once he sends HTTP request to the server.

Reflective XSS attacks have increased multiple times in recent years with URL shortening services that make fake URLs look benign.

2.     Persistent XSS

Persistent attacks are much easier to carry, but are more dangerous for both users and severs. It’s largely a web application vulnerability when the application fails to sanitize user inputs and stores it in a local database. An attacker can insert JavaScript code to customize sessions so that other users are unaware of the risks.


Quick Points

  • JavaScript has access to some of the user’s sensitive information, such as cookies.
  • JavaScript can send HTTP requests with arbitrary content to arbitrary destinations by using XMLHttpRequest and other mechanisms.
  • JavaScript can make arbitrary modifications to the HTML of the current page by using DOM manipulation methods (DOM is also a kind of XSS attack).

XSS Illustration

PART 3: How to Stop Cross Site Scripting

No business can afford to lose trust of its users by executing commands that actually risks their information. That is exactly why detection, prevention, and remediation are always a pressing issue with vulnerabilities like XSS.

A lot of organizations presume that cross-site scripting isn’t exactly a pressing issue. It doesn’t actually put server or database in grave danger after all. However, they should understand that if users are compromised, sooner or later, the problems will challenge your website security.


1.      Validation

Web application developers should fundamentally analyze code for smarter interpretation. The user inputs should be filtered from malicious chain of commands. Malicious codes are widely injected in GET or POST parameter. Both reflective and persistent cross-site scripting vulnerabilities can be dealt with validation.

However, validation brings several code changes leading to last minute whitelisting and black listing, which often leads to rejection of real users. In depth, on-going analysis is required for precision.

2.     Encoding

Why should browser execute inputs as code and not just simple data? Along with validation, filtration and escaping are the best practices to avoid XSS. All the inputs including special characters should be ciphered in respective HTML or URL codes. Other than that, you can also look into inbound/outbound handling too.

Just like validation, encoding also brings its share of limitations. Encoded HTML pages can generate simple text pages, while most modern websites require additional functionalities. Similarly, URLs beginning with “javascript:” will be executed by the server irrespective of the preventive measures.

3.     Testing

A positive XSS prevention model is incomplete with thorough testing of the input fields at regular intervals. Web application scanning has been the ultimate took for raising red flags efficiently for many years now. However, today there is need for manual expert intervention to test web applications for logics that a machine can’t.

Manual application assessment through web application scanning can reveal vulnerabilities in detail. Moving forward, if an organization doesn’t have time, resources, or patience to mend found vulnerabilities, a web application firewall can prevent your application from executing malicious inputs, securing you and your users.

Quick Facts

Start Here

Founder & Chief Marketing Officer, Indusface

Venky has played multiple roles within Indusface for the past 6 years. Prior to this, as the CTO @indusface, Venky built the product/service offering and technology team from scratch, and grew it from ideation to getting initial customers with a proven/validated business model poised for scale. Before joining Indusface, Venky had 10+ years of experience in security industry and had held various mgmt/leadership roles in Product Development, Professional Services and Sales @Entrust.