Getting started in bug bounty feels confusing at first. You read blogs, watch videos, and try payloads, but real-world applications rarely behave the way labs do. This blog is about my first real vulnerability report, how I approached it, what I learned, and why understanding the application mattered more than fancy payloads.

Why I Chose to Test a Chatbot

Chatbots are everywhere now—customer support, onboarding, FAQs. From a security perspective, they are interesting because they:

• Accept user-controlled input

• Render content dynamically

• Depend heavily on client-side JavaScript

Any feature that mixes user input with dynamic DOM rendering is worth attention, especially when security controls are handled on the frontend.

First Observation: Filters Everywhere, But Something Felt Off

At first glance, the chatbot looked secure. Common script tags and event handlers were filtered. JavaScript wasn’t executing, and many payloads failed silently.

But one thing stood out: some HTML was still being rendered instead of displayed as plain text.

That was my first signal.

Step-by-Step Approach I Used to Find the Bug

Instead of jumping straight to exploitation, I followed a structured process:

Step 1: Identify User Input Points

• I looked for places where user input is accepted and displayed back in the interface. The chatbot was a perfect candidate because messages are reflected immediately.

Step 2: Test Rendering Behavior

• I checked whether input was rendered as plain text or interpreted as HTML. Seeing rendered HTML confirmed that user input was being injected into the DOM.

Step 3: Understand the Sanitization Logic

• I tested how the application handled common filters. Some tags were blocked, but others were allowed, indicating partial sanitization rather than safe encoding.

Step 4: Analyze the DOM Insertion Method

• Using browser developer tools, I observed how chat messages were added to the page. This helped confirm that unsafe DOM manipulation methods were being used.

Step 5: Check Persistence Across Reloads

• I refreshed the page to see whether previous messages were reloaded. When they appeared automatically, it revealed client-side storage and re-rendering.

Step 6: Confirm Automatic Execution

• Finally, I confirmed that the injected behavior triggered again on reload without additional user interaction, proving persistence.

Discovering a Persistent DOM-Based XSS

Because the stored input was re-rendered dynamically, it became possible to trigger JavaScript execution without re-entering the input. Once stored, the behavior repeated automatically on reload.

This confirmed a persistent DOM-based XSS, caused by:

• Insufficient HTML sanitization

• Unsafe DOM rendering

• Client-side persistence
  
  

Why This Vulnerability Actually Matters

DOM-based XSS is often underestimated, especially when persistence is handled on the client side. But the impact is still real.

An attacker could:

• Execute arbitrary JavaScript in the site’s context

• Abuse trusted UI elements like chat widgets

• Perform phishing or redirection attacks

• Manipulate page content dynamically
  
  

Responsible Disclosure Over Exploitation

Instead of pushing the vulnerability further, I chose responsible disclosure. The report included clear reproduction steps, minimal proof of execution, and no sensitive data or aggressive actions.

This ensured the issue could be validated safely by the security team.

Lessons I Learned from My First Report

This experience reinforced several important lessons:

1. Filtering alone does not guarantee security

2. Context matters more than payload complexity

3. DOM-based issues require frontend awareness

4. Persistence can exist without a backend database

5. Clear methodology leads to real findings
   
   

Final Thoughts

This first report changed how I approach security testing. Bug bounty is not about memorizing tricks—it’s about observing application behavior, understanding data flow, and being patient.

This was my first real step into bug bounty hunting, and it confirmed that real vulnerabilities reward disciplined thinking.