Ethical Hacking

🛡️ Ethical Hacking — Day 19

XSS Deep Dive: Reflection, DOM Analysis & Secure Testing

⚠️ LEARNING PURPOSE ONLY: Today's tutorial is strictly for educational and defensive cybersecurity learning. Perform every practical exercise only against your local OWASP Juice Shop lab, applications you own, or systems for which you have explicit authorization. Never test XSS against public websites or other users without permission.

Welcome to Day 19.

On Day 18, we learned the fundamentals of Cross-Site Scripting (XSS). Today we'll go deeper into how to analyze an input, find where it is reflected, understand its context, and determine whether the application is safely encoding it.

The goal is not to memorize XSS payloads.

The goal is to understand:

INPUT
  ↓
HTTP REQUEST
  ↓
APPLICATION
  ↓
HTML / DOM
  ↓
BROWSER

🎯 Day 19 Learning Objectives

Today you'll learn:

Reflection points
Input tracing
HTML contexts
Attribute contexts
JavaScript contexts
DOM XSS
Sources and sinks
Browser Developer Tools
Burp HTTP History
Burp Repeater
Response comparison
Safe XSS validation
Output encoding
HTML sanitization
CSP
Secure JavaScript
Laravel XSS prevention
Spring Boot/Thymeleaf XSS prevention
React XSS prevention
Linux practical commands
Windows PowerShell practical commands
macOS practical commands
Writing an XSS finding

1. XSS Review

The basic vulnerability is:

Untrusted Data
      ↓
Unsafe HTML/JavaScript Context
      ↓
Browser
      ↓
Unexpected Interpretation

The secure model is:

Untrusted Data
      ↓
Context-Aware Encoding
      ↓
Safe HTML/DOM
      ↓
Browser

2. What Is a Reflection Point?

A reflection point is a place where your supplied input appears again in the application's response or DOM.

For example, you submit:

XSS-DAY19

and the page displays:

Search results for XSS-DAY19

Your input has been reflected.

The next question is much more important:

Where exactly was it reflected?

3. Reflection Doesn't Mean Vulnerability

Suppose:

Input:
<test>

The application returns:

&lt;test&gt;

The browser displays:

<test>

but treats it as text.

Therefore:

Reflected input
       ≠
XSS

You need to determine whether the browser interprets the data as executable content.

4. Reflection Contexts

Your input may appear inside:

HTML text

<div>USER_INPUT</div>

Attribute

<input value="USER_INPUT">

JavaScript

<script>
const x = "USER_INPUT";
</script>

URL

<a href="USER_INPUT">Link</a>

CSS

<div style="...USER_INPUT...">

Each context has different security requirements.

5. Why Context Matters

This is a critical concept:

HTML encoding
    ≠
JavaScript encoding
    ≠
URL encoding
    ≠
CSS encoding

You cannot safely solve every XSS problem with:

"Just escape the input."

The correct defense depends on where the data is inserted.

6. Start Your Lab

Linux

docker ps

Windows PowerShell

docker ps

macOS

docker ps

Verify Juice Shop:

Linux/macOS

curl -I http://127.0.0.1:3000

Windows

curl.exe -I http://127.0.0.1:3000

7. Open Juice Shop

Open:

http://127.0.0.1:3000

Then start:

Burp Suite
   ↓
Proxy
   ↓
Open Browser

Keep your scope limited to:

127.0.0.1:3000

8. Find an Input

Look for a feature that accepts text.

Examples:

Search
Feedback
Reviews
Comments
Profile fields

Enter a harmless unique marker:

XSS-DAY19-TEST

The unique marker makes it easier to find in Burp and Developer Tools.

9. Capture the Request

Go to:

Proxy
 ↓
HTTP history

Find the request containing:

XSS-DAY19-TEST

Record:

Method:
Endpoint:
Parameter:
Input:

For example:

GET
/rest/...
q=XSS-DAY19-TEST

Your actual Juice Shop version may use a different endpoint.

10. Send to Repeater

Right-click:

Send to Repeater

Then:

Repeater
 ↓
Send

This gives you a repeatable baseline.

11. Baseline Table

Create:

Input	Status	Length	Reflection
`XSS-DAY19-TEST`	___	___	Yes/No
`hello`	___	___	Yes/No
`12345`	___	___	Yes/No

Now we know how the application normally handles input.

12. Test Special Characters

Inside your local lab, test:

<test>

and:

"test"

and:

'test'

and:

&test

These are diagnostic inputs, not destructive payloads.

Record what happens.

13. Inspect the Response

In Burp Repeater, look for your marker.

Search for:

XSS-DAY19-TEST

Then inspect the surrounding content.

For example:

<div>
    XSS-DAY19-TEST
</div>

This is an HTML text context.

14. Attribute Reflection

You might instead find:

<input value="XSS-DAY19-TEST">

Now your input is inside an HTML attribute.

The security requirements are different.

You need appropriate attribute-context handling.

15. Encoded Reflection

You might see:

&lt;test&gt;

instead of:

<test>

That's generally a good sign when the intended context is plain HTML text.

The browser renders:

<test>

as visible text rather than interpreting it as an HTML element.

16. Browser Developer Tools

Now use your browser.

Open:

Developer Tools
 ↓
Elements

Search for:

XSS-DAY19-TEST

Find exactly where it appears.

Ask:

Is it HTML text?
An attribute?
A script?
A DOM-generated element?

17. DOM Inspection

Suppose the server response doesn't contain your input, but the browser displays it.

This can be a clue that JavaScript is processing the value.

Flow:

URL
 ↓
JavaScript
 ↓
DOM
 ↓
Page

This is where DOM XSS analysis becomes important.

18. Sources and Sinks

A very useful XSS concept is:

Source → Sink

A source is where untrusted data enters JavaScript.

Examples:

location.search
location.hash
document.URL
document.referrer

A sink is where that data can become interpreted as HTML or code.

Examples include:

element.innerHTML
element.outerHTML
document.write()
insertAdjacentHTML()

The important question is:

Can untrusted data flow from a source to a dangerous sink without safe handling?

19. DOM XSS Example

Consider:

const value = location.hash.substring(1);

document.getElementById("output").innerHTML = value;

Flow:

URL Hash
   ↓
location.hash
   ↓
value
   ↓
innerHTML
   ↓
DOM

This is a security pattern that deserves review.

20. Safer Version

If the intention is to display plain text:

const value = location.hash.substring(1);

document.getElementById("output").textContent = value;

Now:

Input
 ↓
textContent
 ↓
Text

rather than:

Input
 ↓
innerHTML
 ↓
HTML interpretation

21. Why `innerHTML` Is Dangerous

innerHTML tells the browser:

"Interpret this string as HTML."

That may be perfectly legitimate when the HTML is fully trusted.

But if the content comes from an attacker-controlled source:

Untrusted Data
       ↓
innerHTML
       ↓
HTML Parser

you have a potential XSS problem.

22. Why `textContent` Is Safer

textContent tells the browser:

"Treat this as text."

So:

<test>

remains:

<test>

rather than being interpreted as an HTML element.

For displaying plain text, this is usually the correct choice.

23. Search JavaScript Source

In Developer Tools:

Sources

Search for:

innerHTML

Then:

document.write

Then:

insertAdjacentHTML

Then:

outerHTML

You're looking for:

User-controlled source
        ↓
Dangerous sink

24. Important: Dangerous Sink ≠ Vulnerability

Finding:

innerHTML = ...

doesn't automatically mean XSS.

For example:

element.innerHTML = "<b>Hello</b>";

might use completely trusted static HTML.

You need to trace:

Where does the value come from?

25. Source → Processing → Sink

Use this model:

SOURCE
  ↓
Untrusted Input
  ↓
Processing / Validation
  ↓
Encoding / Sanitization
  ↓
SINK
  ↓
Browser

A vulnerability may exist if:

SOURCE
  ↓
Untrusted Data
  ↓
Dangerous Sink

without appropriate protection.

26. Reflected XSS Analysis

Reflected:

Request
  ↓
Server
  ↓
Response
  ↓
Browser

Example:

/search?q=TEST

Server:

Search results for TEST

The input is immediately reflected.

27. Stored XSS Analysis

Stored:

Request
  ↓
Server
  ↓
Storage
  ↓
Later request
  ↓
Response
  ↓
Browser

This can affect other users.

For your lab, use only:

Your test account
Your test data
Your local database

28. DOM XSS Analysis

DOM-based:

URL / Browser Input
        ↓
Client JavaScript
        ↓
DOM Sink
        ↓
Browser

The server may not be involved at all.

29. Compare the Three

Type	Stored?	Server Response Required?	Main Location
Reflected	Usually no	Yes	Server response
Stored	Yes	Usually	Server + browser
DOM	Not necessarily	Not necessarily	Client JavaScript

30. HTML Encoding

For HTML text contexts, special characters are generally encoded.

For example:

<  → &lt;
>  → &gt;
&  → &amp;
"  → &quot;

After encoding:

&lt;test&gt;

the browser displays:

<test>

as text.

31. Context-Aware Encoding

Remember:

HTML Text
    ↓
HTML Encoding

HTML Attribute
    ↓
Attribute Encoding

JavaScript
    ↓
JavaScript-safe handling

URL
    ↓
URL validation/encoding

Don't use one encoding function everywhere.

32. Output Encoding vs Input Filtering

This is an important distinction.

Input filtering

Input
 ↓
Remove certain characters

Output encoding

Input
 ↓
Store safely
 ↓
Encode for the output context
 ↓
Browser

For XSS prevention, context-appropriate output encoding is generally the more reliable principle.

33. Why Blacklists Fail

A weak defense might say:

Remove:
<script>

But XSS isn't simply:

<script>

There are many HTML, DOM, JavaScript and browser contexts.

Therefore:

Don't build XSS protection around a blacklist of a few strings.

Use proper context-aware encoding and safe APIs.

34. Sanitization

Sometimes an application genuinely needs to allow users to enter HTML.

For example:

Rich text editor
Blog editor
Formatted comments

In such cases, simply escaping all HTML may not be appropriate.

Instead, use a well-designed HTML sanitization mechanism that removes dangerous constructs while preserving allowed formatting.

35. Encoding vs Sanitization

Encoding

Turns data into safe text for a particular output context.

<test>
   ↓
&lt;test&gt;

Sanitization

Removes or transforms unsafe HTML while preserving selected safe HTML.

Use the appropriate technique for the actual requirement.

36. Content Security Policy

Check your local response headers:

Linux/macOS

curl -I http://127.0.0.1:3000

Windows

curl.exe -I http://127.0.0.1:3000

Look for:

Content-Security-Policy

37. CSP Is Defense in Depth

Think:

Output Encoding
       +
Safe DOM APIs
       +
CSP
       +
Secure Cookies

CSP can reduce the impact of some XSS attacks, but:

CSP should not be your primary XSS defense.

38. Cookie Security

Check whether sensitive cookies use:

HttpOnly
Secure
SameSite

Remember:

HttpOnly → JavaScript cannot directly read that cookie
Secure   → Cookie sent over HTTPS
SameSite → Controls certain cross-site cookie behavior

These are useful security controls but don't replace XSS prevention.

39. Laravel XSS Review

Generally escaped

{{ $name }}

Raw HTML

{!! $name !!}

Be extremely careful with raw output.

Use it only when the HTML is trusted or has been properly sanitized for the intended context.

40. React XSS Review

Normal React rendering:

<div>{userInput}</div>

is designed to escape text.

Be cautious with:

dangerouslySetInnerHTML

because it intentionally inserts raw HTML.

Whenever you see it:

Find source
   ↓
Is HTML trusted?
   ↓
If not:
sanitize appropriately

41. Spring Boot / Thymeleaf

Prefer normal escaped template output.

Be cautious with mechanisms that intentionally output raw HTML.

The general principle:

Untrusted data
      ↓
Escaped output
      ↓
HTML

42. JavaScript Secure Coding

Risky for untrusted content

element.innerHTML = userInput;

Better for plain text

element.textContent = userInput;

Also review carefully

document.write(userInput);

element.insertAdjacentHTML("beforeend", userInput);

43. Linux Practical Exercise

Find your local application:

docker ps

Check response:

curl -I http://127.0.0.1:3000

Download HTML:

curl -s http://127.0.0.1:3000/ > juice.html

Search for CSP:

grep -i "content-security-policy" juice.html

Search for a test marker if you have a captured response:

grep -n "XSS-DAY19-TEST" juice.html

44. Windows Practical Exercise

docker ps

Check:

curl.exe -I http://127.0.0.1:3000

Save HTML:

curl.exe -s http://127.0.0.1:3000/ -o juice.html

Search:

Select-String -Path juice.html -Pattern "XSS-DAY19-TEST"

45. macOS Practical Exercise

docker ps

Check:

curl -I http://127.0.0.1:3000

Save:

curl -s http://127.0.0.1:3000/ > juice.html

Search:

grep -n "XSS-DAY19-TEST" juice.html

46. Burp Repeater Workflow

Use this workflow:

1. Capture request
        ↓
2. Send to Repeater
        ↓
3. Send original request
        ↓
4. Record baseline
        ↓
5. Modify ONE parameter
        ↓
6. Send
        ↓
7. Compare
        ↓
8. Inspect reflection context
        ↓
9. Document

Don't change five things at once.

47. Why Change One Thing?

Suppose you change:

Parameter A
Parameter B
Header
Cookie
Path

at the same time.

Then the response changes.

Which change caused it?

You don't know.

Professional testing uses:

One variable
      ↓
One observation
      ↓
Clear conclusion

48. XSS Finding Example

Suppose your authorized lab test discovers:

Parameter:
q

Input:
<test>

Response:
Input reflected without HTML encoding

Context:
HTML

Result:
Browser interprets markup

Your report could say:

Potential reflected XSS: The q parameter is reflected into an HTML context without appropriate output encoding. The application should contextually encode untrusted output before rendering it.

49. Don't Overstate Findings

Avoid writing:

"The entire website is vulnerable."

Instead specify:

Endpoint:
Parameter:
Context:
Behavior:
Impact:
Evidence:
Recommendation:

Good security reports are precise.

50. XSS Impact

Potential impact depends on the application.

It can include:

Unauthorized actions
Account-related abuse
Phishing within trusted pages
UI manipulation
Sensitive data exposure
Session-related abuse
Attacks against privileged users

Impact should be evaluated based on the actual application and affected user privileges.

51. Day 19 Main Lab

Mission: Trace an Input

Choose one local Juice Shop input.

Step 1

Enter:

XSS-DAY19-TEST

Step 2

Capture it with Burp.

Step 3

Send to Repeater.

Step 4

Establish baseline.

Step 5

Search for the marker in the response.

Step 6

Inspect the browser DOM.

Step 7

Determine:

Server reflection?
DOM reflection?
Stored?

Step 8

Determine context:

HTML
Attribute
JavaScript
URL
DOM

Step 9

Test harmless special characters:

<test>
"test"
'test'
&test

Step 10

Document the behavior.

📊 Day 19 Lab Report

╔══════════════════════════════════════╗
║          DAY 19 XSS REPORT           ║
╚══════════════════════════════════════╝

Target:
127.0.0.1:3000

Feature:
____________________________

Endpoint:
____________________________

Method:
____________________________

Parameter:
____________________________

Test Marker:
XSS-DAY19-TEST

Reflected in HTTP response?
Yes / No

Present in DOM?
Yes / No

Stored?
Yes / No / Unknown

Context:
HTML / Attribute / JS / URL / DOM

Special Character Behavior:
____________________________

Encoding Observed:
____________________________

Potential XSS:
Yes / No / Unclear

Evidence:
____________________________

Recommended Fix:
____________________________

🧠 Day 19 Assignment

Answer these questions:

What is a reflection point?
Does reflected input automatically mean XSS?
What is an HTML context?
What is an attribute context?
Why does context matter for XSS prevention?
What is a DOM source?
What is a DOM sink?
Why can innerHTML be dangerous?
Why is textContent safer for plain text?
What is stored XSS?
What is reflected XSS?
What is DOM-based XSS?
What is output encoding?
What is HTML sanitization?
Why is removing <script> not sufficient?
What does CSP do?
What does HttpOnly do?
Why is dangerouslySetInnerHTML worth reviewing?
Why should raw HTML output in Laravel be treated carefully?
Why should you change only one parameter during controlled testing?

🏆 Day 19 Challenge

Create a Source → Sink Map.

Example:

SOURCE
location.hash
     │
     ▼
JavaScript variable
     │
     ▼
Processing
     │
     ▼
innerHTML
     │
     ▼
DOM
     │
     ▼
Browser

Then create the secure version:

SOURCE
location.hash
     │
     ▼
JavaScript variable
     │
     ▼
textContent
     │
     ▼
Plain Text
     │
     ▼
Browser

🔐 Day 19 Golden Rule

Remember:

The most important XSS question isn't "What payload should I use?" It is "Where does untrusted data go, and how does the browser interpret it?"

Use this mental model:

SOURCE
  ↓
UNTRUSTED DATA
  ↓
PROCESSING
  ↓
OUTPUT CONTEXT
  ↓
ENCODING / SANITIZATION
  ↓
BROWSER

And always keep:

DATA ≠ CODE

✅ Day 19 Summary

Today you learned:

Reflection points
Reflected XSS
Stored XSS
DOM XSS
HTML contexts
Attribute contexts
JavaScript contexts
Sources
Sinks
innerHTML
textContent
Output encoding
Sanitization
CSP
Secure cookies
Burp Repeater
Browser Developer Tools
Laravel
React
Spring Boot/Thymeleaf
Linux
Windows
macOS
XSS reporting

🔑 Most Important Lesson

Trace untrusted data from its source to its final browser context. Then use the correct encoding, sanitization, or safe DOM API for that context.

🔜 Day 20 — XSS Practical Lab & Defense

Next we'll consolidate XSS with a more structured local lab:

Reflected XSS analysis
Stored XSS analysis
DOM XSS source/sink tracing
Burp Suite
Browser DevTools
Safe validation methodology
XSS severity and impact
Secure Laravel code
Secure Spring Boot code
Secure JavaScript
CSP
XSS reporting
Linux, Windows and macOS practical sessions

⚠️ LEARNING PURPOSE ONLY: All exercises remain limited to your local/authorized lab. Never test public websites or other people's accounts without explicit authorization.

Author Description

Author Social Links

Post Page Advertisement [Top]

Ethical Hacking XSS Deep Dive: Reflection, DOM Analysis & Secure Testing | Day 19

🛡️ Ethical Hacking — Day 19

XSS Deep Dive: Reflection, DOM Analysis & Secure Testing

🎯 Day 19 Learning Objectives

1. XSS Review

2. What Is a Reflection Point?

3. Reflection Doesn't Mean Vulnerability

4. Reflection Contexts

HTML text

Attribute

JavaScript

URL

CSS

5. Why Context Matters

6. Start Your Lab

Linux

Windows PowerShell

macOS

Linux/macOS

Windows

7. Open Juice Shop

8. Find an Input

9. Capture the Request

10. Send to Repeater

11. Baseline Table

12. Test Special Characters

13. Inspect the Response

14. Attribute Reflection

15. Encoded Reflection

16. Browser Developer Tools

17. DOM Inspection

18. Sources and Sinks

Source → Sink

19. DOM XSS Example

20. Safer Version

21. Why innerHTML Is Dangerous

22. Why textContent Is Safer

23. Search JavaScript Source

24. Important: Dangerous Sink ≠ Vulnerability

25. Source → Processing → Sink

26. Reflected XSS Analysis

27. Stored XSS Analysis

28. DOM XSS Analysis

29. Compare the Three

30. HTML Encoding

31. Context-Aware Encoding

32. Output Encoding vs Input Filtering

Input filtering

Output encoding

33. Why Blacklists Fail

34. Sanitization

35. Encoding vs Sanitization

Encoding

Sanitization

36. Content Security Policy

Linux/macOS

Windows

37. CSP Is Defense in Depth

38. Cookie Security

39. Laravel XSS Review

Generally escaped

Raw HTML

40. React XSS Review

41. Spring Boot / Thymeleaf

42. JavaScript Secure Coding

Risky for untrusted content

Better for plain text

Also review carefully

43. Linux Practical Exercise

44. Windows Practical Exercise

45. macOS Practical Exercise

46. Burp Repeater Workflow

47. Why Change One Thing?

48. XSS Finding Example

49. Don't Overstate Findings

50. XSS Impact

51. Day 19 Main Lab

21. Why `innerHTML` Is Dangerous

22. Why `textContent` Is Safer