Skip to content

Reflected XSS — Search Bar

Field Value
Platform PortSwigger Web Security Academy
Vulnerability Reflected Cross-Site Scripting (XSS)
Difficulty Apprentice
Injection Point Search bar (?search= query parameter)
Goal Execute alert() in the browser via reflected XSS

Phase 1 — Reconnaissance

We land on a blog with a search bar.

Screenshot

Phase 2 — Confirming HTML Injection

Testing whether the search bar reflects HTML without sanitization:

<marquee>Kasane Teto</marquee>
Screenshot

The text scrolled across the page — the HTML tag was rendered by the browser rather than escaped and displayed as literal text. The application is inserting user input directly into the HTML response without encoding. HTML injection is confirmed, and script execution follows naturally.

Phase 3 — Reflected XSS Execution

<script>alert("Kasane Teto")</script>
Screenshot
Screenshot

The alert fired — reflected XSS confirmed. Lab solved. The URL now contains the payload:

/?search=<script>alert("Kasane+Teto")</script>

This URL itself is the attack vector — anyone who clicks it will trigger the script in their own browser context.

After confirming XSS works, testing whether session cookies are accessible:

<script>alert(document.cookie)</script>
Screenshot
Screenshot

The alert fired but showed nothing — the session cookie is not accessible via JavaScript. The reason is the HttpOnly flag.

When a cookie has HttpOnly set, the browser enforces a strict rule: that cookie cannot be read by any JavaScript running on the page — not even JavaScript from the legitimate domain. The cookie is still sent automatically with every HTTP request, but document.cookie will not include it.

Set-Cookie: session=abc123; HttpOnly; Secure
                             ↑
                             JavaScript cannot read this
                             document.cookie returns empty string

HttpOnly does not prevent the cookie from being sent to the server — it only prevents JavaScript from reading it client-side. An attacker with XSS can still perform actions on behalf of the user (make authenticated requests, submit forms) but cannot steal the session token itself to log in from a different machine.

Conclusion

  1. The search bar reflected user input directly into the HTML response without encoding — <marquee> rendered confirmed HTML injection.
  2. Injecting <script>alert("Kasane Teto")</script> executed JavaScript in the browser — reflected XSS confirmed.
  3. The payload travels in the ?search= query parameter — the crafted URL is the delivery mechanism for attacking victims.
  4. document.cookie returned empty because the session cookie has the HttpOnly flag set — XSS execution succeeded but session token theft was prevented by the server-side cookie configuration.