Cross-Site Scripting, Explained With One Example

Cross-Site Scripting (XSS) is a web security vulnerability that happens when a website places untrusted user input into a webpage without properly handling it.

In simple terms:

The website expects data, but the browser ends up treating that data as code or markup.

A Simple Example

Imagine a website has a comment box:

Write a comment:
[________________________]

        [Post Comment]

A normal user might enter:

Great article!

The website displays:

Great article!

So far, everything is fine.

Now imagine the website allows users to submit HTML and places it directly into the page.

A user could enter:

<strong>This text is controlled by the user</strong>

If the website is vulnerable, the browser may interpret the input as HTML and display the text in bold instead of showing the HTML tags as ordinary text.

That may seem harmless, but it demonstrates the underlying security problem:

The website intended to display user data, but the browser interpreted that data as markup.

If an application also allows executable content to be inserted in an unsafe way, this same type of vulnerability can become a real XSS attack.

How Does XSS Happen?

The basic flow looks like this:

User-controlled input
        ↓
     Website
        ↓
   Unsafe output
        ↓
      Browser
        ↓
Content is interpreted as HTML/code

The vulnerability exists because the application failed to properly separate data from content that the browser can interpret.

Why Is XSS Dangerous?

Depending on the type of XSS and the application’s security controls, an attacker could potentially:

• Modify what a user sees on a webpage.
• Perform actions as the victim within the vulnerable application.
• Access sensitive information available to browser-side code.
• Redirect users to malicious content.
• Display convincing fake forms or messages.

The actual impact depends on the application and its security controls.

How Do Developers Prevent XSS?

Developers should ensure that untrusted input is safely handled before it is placed into a webpage.

Common protections include:

• Properly escaping output.
• Treating user input as text rather than HTML when HTML is not required.
• Using safe APIs for inserting content into a webpage.
• Using frameworks with built-in XSS protections correctly.
• Applying a strong Content Security Policy (CSP) as an additional layer of defense.

The key principle is:

Never trust user input.

Try It Safely

You can understand the basic idea using a local practice page.

Compare these two inputs:

Hello World

and:

<strong>Hello World</strong>

If the second input appears as bold text rather than displaying the <strong> tags, the browser has interpreted the input as HTML.

A secure application that intends to display the input as text should instead show:

<strong>Hello World</strong>

This simple experiment demonstrates why applications need to control how user-supplied content is inserted into webpages.

Only test XSS behavior on applications you own or have explicit permission to test.

Key Takeaways

• XSS stands for Cross-Site Scripting.
• It occurs when untrusted input is handled unsafely by a web application.
• A browser may interpret attacker-controlled content as HTML or executable code.
• XSS can affect other users who view vulnerable content.
• Stored, reflected, and DOM-based XSS are common categories.
• Proper output encoding and safe handling of untrusted data are important defenses.
• Always practice XSS in an authorized lab environment.

Next Lesson

Next, learn How Authentication Works to understand how websites identify users, manage sessions, and protect accounts.