# What Is Cross-Site Scripting (XSS)? Stored, Reflected, DOM-Based XSS and Prevention Methods

**URL:** https://securesys.com.tr/en/learning/web-application-security/what-is-cross-site-scripting-xss-prevention

### What Is Cross-Site Scripting (XSS)?

![What is Cross-Site Scripting (XSS)? Stored, Reflected and DOM-Based XSS](/images/bilgi-merkezi/covers/cover-xss.webp)

Cross-Site Scripting (XSS) is a critical security vulnerability that allows an attacker to inject malicious client-side code (usually JavaScript) into a web application so that it runs in the browsers of other users. While [SQL Injection](/en/learning/web-application-security/what-is-sql-injection-types-prevention) targets the database directly, XSS targets the user — so session information, user accounts and any sensitive data accessible through the browser are also put at risk.

In modern web applications, XSS vulnerabilities can appear in comment fields, messaging modules, search boxes, profile information, management panels and when data returned from an API is processed on the client side. Many organisations see XSS merely as a "printing JavaScript to the screen" problem, but a successful XSS attack can lead to serious consequences such as hijacking user sessions, phishing and unauthorised operations.

### Why Is XSS a Critical Security Risk?

Even though XSS attacks do not compromise the server directly, they are extremely dangerous because they target real users who trust the application to carry out their operations. Malicious code running in the browser of a user with administrator privileges in particular can give the attacker indirect but powerful control over the system — leading to the hijacking of administrator sessions, viewing of corporate data on the client side, and theft of authentication credentials.

### Types of XSS

#### \1. Stored XSS (Persistent XSS)

Occurs when the attacker saves malicious code into the application's database. The malicious content is then served to every user who views the page — through fields such as product reviews, support tickets, forum messages or profile descriptions. This type of XSS is among the highest-impact scenarios.

#### \2. Reflected XSS

Occurs when malicious input is returned directly to the user by the application; usually seen through search pages, error messages or URL parameters. The attacker sends a specially crafted link to the user, and when opened the malicious code runs in the browser. It is often used together with social engineering attacks.

#### \3. DOM-Based XSS

One of the most common XSS types in modern JavaScript applications. The vulnerability originates not from the server but from the client-side JavaScript code. It must be examined carefully in single-page applications (SPA) and systems using frameworks such as React, Angular or Vue.

### A Real-World Scenario

In an organisation's help-desk application, users could add descriptions to support tickets. During the penetration test it was found that malicious JavaScript added to the description field was not filtered. Each time the support team viewed the ticket, the malicious code ran and session information was sent to a server under the attacker's control. The attacker did not hack the system directly, yet by hijacking the administrator account gained full control over the application.

### SecureSys XSS Testing Approach

We do not settle for automated scanner output alone in XSS testing. Every application is analysed manually, examining all points where user input is processed: reflected/stored/DOM-based XSS scenarios, HTML injection checks, rich-text editor security, Content Security Policy (CSP) configuration and cookie security flags (HttpOnly, Secure, SameSite).

### How Can XSS Be Prevented?

- User input must be encoded appropriately for its context.
- HTML output must be filtered securely.
- Safe DOM methods should be preferred over unnecessary `innerHTML` usage.
- Content Security Policy (CSP) must be enabled.
- HttpOnly, Secure and SameSite attributes must be used on cookies.
- Regular code reviews and independent penetration tests must be carried out.

### Potential Outcome and Business Impact

| Potential Outcome | Business Impact |
| --- | --- |
| Hijacking of session information | Unauthorised user access |
| Takeover of the administrator account | Loss of control over critical systems |
| Display of phishing screens | Erosion of user trust |
| Reading sensitive data on the client side | KVKK and data-breach risk |

To have your application tested against XSS and other client-side vulnerabilities, review our [Web Application Penetration Testing Service](/en/services/web-application-security-test-service) page.