What Is a Cross-site Scripting (XSS) Attack? | Feroot
Attacks and Threats

What Is a Cross-Site Scripting (XSS) Attack?

In cross-site scripting (XSS) attacks, malicious scripts are injected into trusted websites. In XSS attacks a threat actor uses a web application or website to send malicious code, generally in the form of a client-side script, to the end user’s browser.

The attacker places the malicious code into a client-side script, and the user’s browser assumes that the site or application is trusted. Instead of blocking the activity, the browser executes the script, giving it access to any cookies, session tokens, or other sensitive information that the browser stored or used with that site.

The two primary types of XSS attacks are:

  • Persistent (stored XSS): Malicious script permanently stored on the vulnerable application’s server.
  • Reflected (non-persistent XSS): Malicious content delivered when the vulnerable application returns a response to the user input, such as an error message, without storing the code on the server.

Mitigating client-side XSS vulnerabilities is fundamental to application security.

Do you know if your business is the victim of a cross-site scripting (XSS) attack? Find out with a free in-person assessment. No strings attached. Click to schedule.

How Do Cross-Site Scripting Attacks Work?

XSS attacks take advantage of browsers executing commands without evaluating a request. Since they can’t distinguish between legitimate and malicious markup text, the browser executes the text it receives, then delivers to the user requesting it. In a cross-site scripting attack, threat actors insert malicious code that allows them to impersonate the end-user, rerouting the information sent to the application. 

Whether reflected or persistent, the attack typically follows these steps:

  • Attackers find a way to compromise the website or application by gaining access to the target page where users can input information, usually one containing HTML or JavaScript.
  • Attackers inject the malicious code into that webpage. 
  • Victim’s browser sends a GET request to the compromised website
  • Compromised page’s response delivers the malicious script. 
  • Victim’s browser executes the malicious script. 
  • The next time the victim’s browser sends a GET request, the request goes to the attacker’s server. 
  • The attacker collects any sensitive information that the victim sends from the browser. 

How to Defend & Protect Against Cross-Site Scripting Attacks?

Traditional server-side security tools won’t protect against client-side attacks because the malicious code never makes it to the server. Following secure coding best practices is fundamental to cross-site scripting prevention. 

Some best practices include:

  • Building security into the software development life cycle using DevSecOps.
  • Using an automated client-side attack surface management tool.
  • Maintaining secure code libraries.
  • Automated website crawls to look for unauthorized scripts and anomalous code behavior.
  • Apply JavaScript security policies.
  • Using an output encoding library.
  • Reviewing dangerous contexts for variables, including callback functions, areas handling URLs in code, JavaScript event handlers, unsafe JavaScript function.
  • Sanitizing HTML.
  • Automated Content Security Policies (CSPs) to create allowlists that prevent content from being loaded.

Learn more about the impact of cross-site scripting attacks. Download The Ultimate Guide to Client-Side Security.

Who Is Targeted by Cross-Site Scripting Attacks?

Threat actors target any organization with a website that collects information – either on the website or by developing a web application. Industries that collect sensitive personal information, like credit card data or protected health information (PHI), face a greater risk. 

Primary  industries targeted by malicious actors include:

Other industries include

  • Real Estate
  • Technology & Cybersecurity
  • Distribution & Transportation
  • Education
  • Manufacturing
  • Energy
  • Distribution & Transportation

Who Is Impacted by Cross-Site Scripting Attacks?

According to research, 10.6% of the 6,443 vulnerabilities published between November 2021 and January 2022 involve cross-site scripting. Cross-site scripting attacks impact anyone interacting with a compromised website or web application. 

Remote Employees

Remote work relies on digital communications, often using web applications or online forms to submit information. For example, an XSS attack can impact remote employees by stealing:

  • Login ID
  • Password
  • Date of birth
  • Health insurance information
  • Personal health data, such as medications or conditions


Retailers and e-commerce companies use their websites to sell consumer products. When attackers target these sites, they can impact consumers by stealing:

  • Name
  • Email address
  • Credit card information
  • Address

Business Customers

If threat actors target a company that develops software, the company’s customers become victims. The attack can lead to a data breach that includes:

  • Sensitive company information 
  • Sensitive information about the company’s customers

Application and Website Development Companies

Since web applications are a primary attack vector, these attacks impact application development companies because threat actors target them. For example, any applications or websites using JavaScript can be compromised when an attacker injects malicious JavaScript. 

Types of Cross-Site Scripting Attacks

While there are four types of XSS attacks, it’s also important to know that where the untrusted data is used risk increases. This means that for several of the types, the XSS can be:

  • Server XSS: Untrusted user-supplied data is in an HTTP response that the server generates
  • Client XSS: Untrusted user-supplied data updates the DOM with an unsafe JavaScript call

Persistent (Stored-XSS or Type I XSS)

A stored XSS can be either a Client XSS or Server XSS. The target servers permanently store the injected script. When the victim’s browser sends a request to the server, the response delivers the malicious script. Some examples of locations where attackers can store the malicious content include:

  • Databases
  • Message forums
  • Visitor logs
  • Comment fields

Reflected XSS (Non-Persistent or Type II XSS)

A reflected XSS can be either a Client XSS or Server XSS.  Threat actors usually deliver a reflected XSS attack by starting with a phishing attempt or via another website. This tricks the user into:

  • Clicking a malicious URL
  • Browsing a malicious site
  • Submitting a form created by the attacker

When the user’s browser submits this request, the injected script “reflects” off the web server, returning an error message or search result that includes some or all of the original input. When the browser receives this information, it executes the code. 

Blind Cross-Site Scripting

Considered a form of persistent XSS, a blind cross-site scripting is when a server stores the malicious code, reflecting it back to the victim from the backend application. 

DOM Based XSS (Type-0)

A DOM Based XSS is a subset within the Client XSS type, that can be a stored or reflected attack type. A modification of the DOM “environment,” the part of the user’s browser that the original client side script uses, leads the client side code to run in an “unexpected” manner. 

Cross-Site Scripting Attacks: Impacts

Depending on the person/entity impacted, the types of impacts vary. 

Remote Employees and Consumers

Any cross-site scripting attack targets sensitive information, often for financial gain. Consumers or remote employees impacted by the attack may experience:

  • Identity theft
  • Credential theft
  • Fraudulent charges from illegal purchases

Businesses and Application/Website Developers

On the other side, the business with the impacted application or website needs to respond to the attack. They may experience:

  • Reputational damage
  • Customer churn
  • Loss of revenue
  • Compliance fines associated with failure to comply with regulations or standards, like those required by the Payment Card Industry Data Security Standard (PCI DSS)
  • Legal costs, including lawyer fees and customer reimbursement

Free Assessment

Security for Everyone that Visits Your Website

Find out if your web application is hiding vulnerable, malicious, or dangerous code that could damage your customers and your business. No payment information required.

Back to education center