While testing the Parser service of a SaaS automation platform (example.com), I identified a Reflected Cross-Site Scripting (XSS) vulnerability. The issue was caused by improper handling of the error_description parameter, which was directly reflected in the HTML response.

Interestingly, I had tested this target a year ago and missed this endpoint. When I came back later with a deeper approach, I found not only this XSS but multiple other bugs in the same flow. This shows why re-testing with fresh eyes is always valuable.

Understanding the Target

The Parser service is part of the platform's email-to-automation workflow. Its purpose is to parse incoming email content, validate it, and trigger automated actions ("Zaps").

During error handling, the service displays error messages back to the user when something goes wrong in the parsing/validation stage. That's where I noticed the parameter error_description being reflected in the UI.

Key observation:

  • Error messages are often overlooked by developers.
  • They commonly take backend error strings and push them into the front-end response.
  • Perfect spot to check for XSS or HTML injection.

Root Cause & Flow

  • The endpoint /complete/parser/ accepts query parameters like error and error_description
  • Instead of sanitizing, the app directly reflected the value of error_description into the HTML response.
  • This created a sink where user-controlled input could become executable JavaScript.

So the flow looked like this:

User Input (error_description param) → Server → HTML Response → Browser Executes

Steps to Reproduce

  1. Navigate to the vulnerable endpoint.

https://example.com/complete/parser/?error=invalid_request&error_description=Transform+algorithm+not+supported.%3Cscript%3Ealert(document.cookie)%3C/script%3E&state=cc%0Ass

2. Observe that the injected script <script>alert(document.cookie)</script> executes in the browser.

Impact

  • Theft of session cookies or tokens.
  • Malicious script injection to phish users.
  • DOM manipulation to redirect or mislead users.
  • Could be chained with CSRF/Clickjacking for larger impact.

🕒 Timeline

  • March 31, 2025 — Report submitted.
  • May 23, 2025 — Triaged by the program.
  • June 25, 2025 — Report rewarded with $366 bounty.

💡 Takeaway

  • Always test all parameters, even those that look harmless like error_description.
  • Don't ignore error-handling flows — they're often a goldmine for XSS.
  • Revisiting the same target after some time can expose bugs you missed earlier.

✅ Connect and Engage

💬 What's your experience with XSS in error-handling parameters?

Follow me on Twitter: @a13h1_

Keep clapping, commenting, and sharing your thoughts — your support motivates me to share more real bug bounty stories!