Cross-Site Scripting (XSS) exploits a vulnerable website by injecting JavaScript that executes in the user's browser

There are several types of XSS attacks, one of which is Reflected XSS, where the injected payload is delivered through the current HTTP request

For this lab activity, the search bar does not properly handle user input before displaying it on the page

None

In the search bar, enter any term; in my case, I used my name

None

Let's look at the search function's source code. Since I'm using Windows, I'll use the shortcut "Ctrl + U"

<section class=blog-header>
                        <h1>3 search results for 'bea'</h1>
                        <hr>
                    </section>
                    <section class=search>
                        <form action=/ method=GET>
                            <input type=text placeholder='Search the blog...' name=search>
                            <button type=submit class=button>Search</button>
                        </form>
                    </section>

The search works by sending user input as a GET parameter, which the server reflects directly into the HTML response. This is a vulnerability because the input is not properly encoded, allowing injected JavaScript to execute

Let's try a basic JavaScript payload into a vulnerable website (lab activity)

<script>alert(1)</script>
None

Upon clicking "Search" see what happens…

None

A pop-up alert appeared, indicating that the script executed successfully

Let's study the source code again

 <section class=blog-header>
                        <h1>0 search results for '<script>alert()</script>'</h1>
                        <hr>
                    </section>
                    <section class=search>
                        <form action=/ method=GET>
                            <input type=text placeholder='Search the blog...' name=search>
                            <button type=submit class=button>Search</button>
                        </form>
                    </section>

As you can see, the payload we entered was sent by the browser to the search parameter using a GET request, resulting in something like this:

/?<script>alert()</script>
None

The server then takes that value, uses it to look up matching results, and displays the output directly on the website

Since the input field is not properly escaped, the browser interprets the payload as actual code rather than plain text

In this lab, the search bar reflects user input directly into the page using a GET parameter, which is sent to the server and returned in the HTML response. Since the input is not properly encoded or escaped, injected JavaScript such as <script>alert(1)</script> is interpreted and executed by the browser instead of being displayed as plain text, confirming the vulnerability