Ethical Hacking Cross-Site Scripting

Cross-Site Scripting, shortened to XSS, is a web weakness that lets an attacker place harmful script code inside a page that other users view. The browser trusts the page and runs the code. Ethical hackers test for XSS so that developers can close the gap before real attackers find it.

The Core Problem

Websites often display text that users type, such as comments, names, and search terms. A safe site treats that text as plain words. A weak site treats it as code. The browser runs whatever the visitor typed, with the full trust of the website.

Picture a notice board at a school. Students pin messages for others to read. One student pins a note that reads like an instruction, and a trusting reader follows it. XSS works the same way on a web page.

Three Types of XSS

Reflected XSS

The harmful input travels in a link or form and bounces straight back in the response. The victim must click a crafted link. Search result pages often show this weakness.

Stored XSS

The site saves the harmful input in a database, such as in a comment. Every visitor who opens the page runs the code. This type causes the most damage.

DOM-Based XSS

The flaw lives in the page's own browser-side script, which writes user input into the page unsafely. The server never sees the harmful part.

Stored XSS Flow

[Attacker posts comment with script]
              |
              v
      [Server saves comment]
              |
              v
[Visitor opens the page] --> [Browser runs the script]
              |
              v
   [Visitor's data or session at risk]

What an Attacker Could Gain

• Theft of session cookies, which leads to account takeover.
• Fake login boxes that collect passwords.
• Redirection to harmful websites.
• Changes to what the page shows.
• Actions performed in the victim's name.

Safe Testing in a Lab

Testers prove a weakness with a harmless message. A popular check types a tiny script that opens a pop-up box saying "XSS". If the pop-up appears, the page runs user input as code.

Input typed in the search box:
<script>alert('XSS')</script>

Safe page shows the plain text.
Weak page shows a pop-up box.

Practice this on DVWA, OWASP Juice Shop, or another application built for training. Do not test live websites without written approval.

Where Testers Look

Location	Example
Search boxes	Results page repeats the search word
Comment forms	Posts display to every visitor
Profile fields	Display names shown to other users
URL parameters	Error messages that repeat the input
Contact forms	Messages viewed by admin staff

Prevention Methods

Output Encoding

Developers convert special characters into harmless text before showing them. The symbol < turns into a safe code that displays as a character and never starts a script.

Input Validation

The server accepts only expected formats. A phone number field accepts digits and nothing else.

Content Security Policy

This browser rule tells the page which script sources to trust. Unknown scripts get blocked.

HttpOnly Cookies

This flag hides session cookies from scripts, so a successful XSS cannot read them.

Modern Frameworks

Tools such as React and Angular encode output by default. Developers who avoid unsafe features gain strong protection.

Reporting an XSS Finding

A good report names the page, the vulnerable field, the proof steps, a screenshot of the pop-up, the risk level, and the fix. Clear writing helps developers repair the issue quickly.