Yesterday we discussed SQL Injection, a vulnerability that targets databases. Today we'll look at another common web application vulnerability from the OWASP Top 10:

Cross-Site Scripting, usually called XSS.

Unlike SQL Injection, which targets databases, XSS targets users and their browsers.

What is Cross-Site Scripting (XSS)?

Cross-Site Scripting happens when an attacker injects malicious scripts into a website.

When other users visit the affected page, the script runs in their browser as if it came from the trusted website.

This means the attacker can interact with the user's session, data, or actions.

In simple terms, the website unknowingly delivers malicious code to its users.

How XSS Works

Web applications often accept user input such as:

  • Comments
  • Search fields
  • Forms
  • Profile information

If the application does not properly filter or sanitize that input, attackers can insert JavaScript code.

When another user loads that page, the script executes in their browser.

Because the script runs within the website's environment, the browser trusts it.

Simple Example

Imagine a comment section on a website where users can post messages.

A normal comment might look like:

Great article! Thanks for sharing.

But an attacker could submit something like:

<script>alert('Your session is being tracked')</script>

If the website does not filter this code, it may execute when other users open the page.

This is a very basic example, but real attacks can be much more harmful.

What Attackers Can Do with XSS

A successful XSS attack can allow attackers to:

  • Steal session cookies
  • Hijack user accounts
  • Capture keystrokes
  • Redirect users to malicious websites
  • Display fake login forms

In many cases, attackers try to steal session cookies to take control of user accounts.

Types of XSS Attacks

There are three common types of Cross-Site Scripting attacks.

1. Stored XSS

The malicious script is permanently stored on the server, such as in a database.

Every user who loads the page executes the script.

2. Reflected XSS

The malicious script is included in a link or request.

When the victim clicks the link, the script executes immediately.

3. DOM-Based XSS

This attack occurs in the browser itself when JavaScript modifies page content in an unsafe way.

It does not always involve the server directly.

Why XSS Happens

XSS vulnerabilities usually occur because applications:

  • Do not sanitize user input
  • Fail to encode output properly
  • Trust user-provided data

Web applications that allow user-generated content are especially vulnerable.

How Developers Prevent XSS

Developers can reduce XSS risks by following secure coding practices.

Common protections include:

  • Input validation
  • Output encoding
  • Content Security Policy (CSP)
  • Using secure frameworks that handle user input safely

These methods help ensure that user input is treated as data, not executable code.

Connection to the CIA Triad

Cross-Site Scripting mainly affects:

Confidentiality, because attackers may steal user data or session cookies.

It can also impact Integrity if attackers manipulate page content.

Final Thoughts — Day 11 Reflection

XSS shows that even simple features like comment sections or search fields can introduce serious security risks if not handled carefully.

For developers, validating and sanitizing input is essential.

For security professionals, understanding XSS is a key step in learning web application security.

Tomorrow, we will explore another important concept in cybersecurity:

Authentication vs Authorization.

Day 11 complete. 19 days to go. 🔐