Introduction

Cross-site Scripting, commonly called XSS, is a web security vulnerability where untrusted data is displayed in a web page in an unsafe way.

In an XSS vulnerability, a browser may treat user-provided data as executable script or active content instead of plain text.

XSS is dangerous because the malicious code runs inside the user’s browser in the context of the trusted website. This can affect user sessions, page behavior, sensitive information, and user trust.

Easy Real-Life Example

Normal situation:
Student writes: "Good morning"
Notice board displays: "Good morning"

Unsafe situation:
Student writes something that looks like an instruction.
Notice board follows it instead of displaying it as text.

Web application:
User input should be displayed as text,
not executed as browser code.

XSS prevention means making sure user input remains data and never becomes executable code.

What is Cross-site Scripting?

Cross-site Scripting is a vulnerability where malicious client-side code is injected into a trusted web page and executed by another user’s browser.

The malicious code is usually related to browser-executed technologies such as JavaScript or HTML-based behavior.

Simple Concept

User enters data.
Application stores or displays the data.
Browser reads the page.
If unsafe data is interpreted as code,
XSS can happen.

Why XSS is Dangerous

XSS is dangerous because the injected code runs in the browser of the victim user. The browser may trust that code because it appears to come from the original website.

How XSS Happens

XSS usually happens when an application accepts input and later includes that input in a page without proper output encoding, sanitization, or safe rendering.

Common XSS flow:
1. User or attacker provides input.
2. Application accepts or stores the input.
3. Application displays the input in a web page.
4. Browser interprets unsafe content as code.
5. Malicious behavior runs in the browser.

The root problem is that the application does not clearly separate trusted page code from untrusted user data.

Where XSS Can Appear

XSS can appear in many places where user-controlled data is displayed.

Types of XSS

XSS is commonly discussed in three major types: reflected XSS, stored XSS, and DOM-based XSS.

Reflected XSS

Reflected XSS happens when user input from a request is immediately included in the page response without safe handling.

Example situation:
User searches for a keyword.
Application shows:
"You searched for: userInput"

Risk:
If userInput is not encoded,
the browser may treat unsafe characters as active content.

Reflected XSS is usually linked to input that appears in the current response, such as search text, error messages, filters, or URL parameters.

Stored XSS

Stored XSS happens when unsafe input is saved in a database, file, or other storage and later displayed to users.

Example situation:
User submits a product review.
Application stores the review.
Other users open the product page.
Stored review is displayed unsafely.

Risk:
Many users may be affected because the unsafe content is persistent.

Stored XSS can be more dangerous than reflected XSS because the malicious content can remain in the application until removed.

DOM-Based XSS

DOM-Based XSS happens when client-side JavaScript takes untrusted data and inserts it into the page in an unsafe way.

Example situation:
JavaScript reads data from the URL.
JavaScript directly inserts that data into the page structure.

Risk:
Browser-side code creates unsafe content without proper encoding or safe APIs.

DOM-based XSS can be harder to notice because the problem may exist mainly in frontend code rather than server-side response generation.

XSS vs SQL Injection

XSS and SQL Injection are both injection vulnerabilities, but they affect different interpreters.

Input Validation Helps, But Is Not Enough

Input validation checks whether data is expected before accepting it.

Validation can reduce risk, but it should not be the only XSS defense because valid text may still contain characters that need safe output handling.

Input validation asks:
"Is this input acceptable?"

Output encoding asks:
"How should this value be safely displayed?"

Output Encoding as a Main Defense

Output encoding converts special characters into safe representations before displaying data.

This helps the browser display user input as text instead of interpreting it as code.

Unsafe Output Concept

DISPLAY userComment directly inside web page

Safer Output Concept

safeComment = HTML_ENCODE(userComment)

DISPLAY safeComment inside web page

Encoding should be based on the output context, such as HTML body, HTML attribute, URL, JavaScript, or CSS.

Context-Specific Encoding

Different output locations need different encoding rules.

HTML Sanitization

Sometimes an application may allow limited HTML formatting, such as bold text or simple links in comments.

In that case, output encoding alone may not match the feature requirement because the application intentionally allows some HTML. The safer approach is to use a trusted HTML sanitization library that removes unsafe markup and keeps only allowed safe elements.

Example:
Allowed:
- Simple formatting
- Safe links

Not allowed:
- Scripts
- Unsafe event handlers
- Dangerous URLs
- Unknown active content

Safe DOM Handling

Frontend code should avoid inserting untrusted data as raw HTML.

Developers should prefer safe text rendering approaches that treat content as text.

Risky DOM Concept

Set page content using raw HTML from user input.

Safer DOM Concept

Set page text using a safe text-only method.

This keeps user input from being interpreted as HTML or script.

Content Security Policy

Content Security Policy, or CSP, is a browser security control that can reduce the impact of XSS by controlling what scripts and resources the browser is allowed to load or execute.

CSP is useful, but it should be treated as defense in depth, not as a replacement for fixing XSS vulnerabilities.

Defense in depth:
1. Validate input.
2. Encode output.
3. Use safe framework rendering.
4. Sanitize allowed HTML.
5. Add Content Security Policy.
6. Review and test security-sensitive code.

HttpOnly Cookies

If an application uses cookies for session management, HttpOnly cookies can help reduce certain script-based access to cookies.

HttpOnly cookies do not prevent XSS itself, but they can reduce the impact of some XSS scenarios.

Student-Friendly Example: Comment Box

Suppose a student portal allows users to post comments.

Bad Code Concept

INPUT comment

SAVE comment

DISPLAY comment inside page

This is unsafe because the application displays user input directly without safe output handling.

Improved Secure Version

INPUT comment

IF comment is empty OR length of comment > 500 THEN
    DISPLAY "Invalid comment"
    STOP
END IF

SAVE comment as text data

safeComment = HTML_ENCODE(comment)

DISPLAY safeComment inside page

This improved version validates comment length and encodes output before displaying it.

Real-World Example: Product Review

In an e-commerce application, product reviews are written by users and displayed to other users. This makes review sections a common place where stored XSS risk must be considered.

Common Beginner Mistakes

Best Practices to Prevent XSS

Prerequisites Before Learning XSS

Students should understand the following topics before learning Cross-site Scripting deeply:

Trace Table Example: Safe Comment Display

FUNCTION displayComment(comment)
    IF comment is empty THEN
        RETURN "Invalid comment"
    END IF

    IF length of comment > 500 THEN
        RETURN "Comment too long"
    END IF

    safeComment = HTML_ENCODE(comment)

    RETURN safeComment
END FUNCTION

Practice Activity: Fix Unsafe Comment Display

Improve the following pseudocode by applying XSS prevention practices.

INPUT comment

SAVE comment

DISPLAY comment inside web page

Sample Improved Version

INPUT comment

IF comment is empty THEN
    DISPLAY "Invalid comment"
    STOP
END IF

IF length of comment > 500 THEN
    DISPLAY "Comment too long"
    STOP
END IF

SAVE comment as text data

safeComment = HTML_ENCODE(comment)

DISPLAY safeComment inside web page

The improved version validates input and encodes output before displaying it.

Practice Test Cases

XSS Prevention Checklist

Mini Quiz

Interview Questions on Cross-site Scripting Concept

Quick Summary