Bright is now integrated with GitHub Copilot

Check it out! →
Product overview

See how dev-centric DAST for the enterprise secures your business.

Web attacks

Continuous security testing for web applications at high-scale.

API attacks

Safeguard your APIs no matter how often you deploy.

Business logic attacks

Future-proof your security testing with green-flow exploitation testing.

LLM attacks

Next-gen security testing for LLM & Gen AI powered applications and add-ons.

Interfaces & extensions

Security testing throughout the SDLC - in your team’s native stack.


Connecting your security stack & resolution processes seamlessly.


Getting started with Bright and implementing it in your enterprise stack.

Book a demo

We’ll show you how Bright’s DAST can secure your security posture.


Check out or insights & deep dives into the world of security testing.

Webinars & events

Upcoming & on-demand events and webinars from security experts.


Getting started with Bright and implementing it in your enterprise stack.

Case studies

Dive into DAST success stories from Bright customers.


Download whitepapers & research on hot topics in the security field.

About us

Who we are, where we came from, and our Bright vision for the future.


Bright news hot off the press.

Webinars & events

Upcoming & on-demand events and webinars from security experts.

We're hiring

Want to join the Bright team? See our open possitions.

Bug bounty

Found a security issue or vulnerability we should hear about? Let us know!

Contact us

Need some help getting started? Looking to collaborate? Talk to us.

Resources > Blog >
Cross Site Scripting in JavaScript: Everything You Need to Know

Cross Site Scripting in JavaScript: Everything You Need to Know

Admir Dizdar

What is Cross Site Scripting (XSS)

With Cross Site Scripting, attackers execute malicious JavaScript within a victim’s browser to steal session cookies and impersonate a user, as well as using XSS to deface websites, spread malware, phish for user credentials, support social engineering techniques, and more.

In this article:

Types Of XSS

There are three types of cross site scripting, namely:

Reflected XSS

Reflected XSS occurs when the website allows for malicious scripts to be injected into it. An attacker then sends the link of the targeted website containing the malicious script to other users. Once  the link (mostly anchor links) is opened, the script executes and the attacker is able to steal the user’s session cookies. 

This is an efficient attack as it allows for the script to fire off every time a new user opens the malicious link. 

For example, a website “” could have a search functionality that would look like:

Once the user inputs the data into the search field, the url would look like this:”test”

However, the lack of proper sanitization could result in malicious code being injected into the input value. It would look something like this:<script>/*snippet of dangerous code*/</script>

This is all that’s required for an attacker to spread the malicious code to every visitor using this link, and is why Reflected XSS is so dangerous and widespread.  Additionally, it doesn’t even need to store the data to the servers of the web application, allowing it to fly under the radar.

DOM-based XSS

Dom-based cross site scripting is mainly used for hijacking the user sessions, allowing the attacker to gain unauthorized access to the website. 

An  attacker sends the malicious code to vulnerable functions such as eval(), prompting JavaScript to execute the code via the said function. As a consequence, the victim application runs the malicious script, giving the attacker access. 

Stored XSS

Stored XSS attacks use HTTP requests to gain unauthorized access and exploit vulnerabilities on the website. 

Simply put, the attacker exploits the lack of input sanitation and manages to add malicious JavaScript code to the request. If the website requests an input field, the lack of proper sanitation allows the attacker to introduce this code, exploiting vulnerabilities on the website. 

Any user that opens the affected page of the website is affected,  given that the malicious code executes in the browser. 

How XSS Vulnerability Happens in JavaScript

There are multiple ways to inject an XSS vulnerability in JavaScript. In fact, JavaScript is the weak point of most websites and applications, given that JavaScript can dynamically add content to the rendered page. If an  attacker manages to send their own snippet of JavaScript code to the server, it will execute and result in potentially dangerous attacks to your web application. 

The primary cause for this is due to a lack of input sanitisation by the developer. This occurs predominantly with contact forms or similar input fields. If they aren’t handled properly, the attacker can inject their malicious code into that input field, causing the website to run the malicious code.

A good example of a dangerous snippet of code on a website is innerHTML. This allows the attacker to directly modify the website by sending malicious data via JavaScript, and executing it using innerHTML. 

How to Prevent Cross Site Scripting Attacks in JavaScript

There are a few popular methods in preventing Cross Site Scripting attacks:

  • Input validation
  • WAF (Web Application Firewall)
  • Content security policy

Input Validation

The best way to prevent cross site scripting attacks is to ensure every input field is validated.

You should always replace sensitive characters that may cause disruption with their entities. Even though they display the same way, entities cannot generate HTML, saving you potential failures in the future. 

There are many ways in which you can validate the user’s input using JavaScript, such as using vanillaJS, or  external libraries such as jQuery’s validator, which is highly regarded for its simplicity in practical terms. 

Even though it’s often impossible to do so, try restricting the user input to a specified list whenever you can, such as when selecting a currency, country, etc.


Another method of defending against XSS, as well as various other attacks, is by using a Web application firewall (WAF).  which continuously monitor and intercept these attacks. However, WAFs should be used as a last-resort defensive measure and do not offer 100% protection – being secure by design should be your main priority.

Content Security Policy

Creating content security policy (CSP) is perhaps the most efficient way of preventing XSS and other  vulnerabilities. It prevents XSS by white-listing URLs the browser can load and execute JavaScript from. By specifying specific CSP directives, the server prevents the browser from executing any JavaScript that comes from an untrusted URL. The CSP works as a white list, where only domains listed are allowed to execute and everything else is blocked.

XSS Protection in JavaScript with Bright

As a developer, being able to easily detect and fix XSS issues before they hit production is a must.

With Bright you can easily detect XSS, either as a standalone scanner or fully and seamlessly integrated into your development pipelines, with NO false positives. 

Sign up for a FREE account here to start scanning your web applications and APIs today 


IASTless IAST – The SAST to DAST Bridge

Streamline appsec with IASTless IAST. Simplify deployment, enhance accuracy, and boost your security posture by combining SAST and Bright’s DAST.

Bringing DAST security to AI-generated code

AI-generated code is basically the holy grail of developer tools of this decade. Think back to just over two years ago; every third article discussed how there weren’t enough engineers to answer demand; some companies even offered coding training for candidates wanting to make a career change. The demand for software and hardware innovation was

5 Examples of Zero Day Vulnerabilities and How to Protect Your Organization

A zero day vulnerability refers to a software security flaw that is unknown to those who should be mitigating it, including the vendor of the target software.

Get our newsletter