This post is for Day 1 of the Mercari Advent Calendar 2025, brought to you by @philolo1 from the Mercari Help Center team.

Introduction

At Mercari Engineering, we focus on learning and using cutting-edge technologies like AI-assisted development tools, and we value fundamentals like security.

In this post, I will share how I rediscovered my passion for security through Mercari’s Security Champion Program and how that learning helped me detect a Cross-Site Scripting (XSS) vulnerability in a 3rd party WebSocket integration during development before it ever reached production.

Phase 1: Rediscovering Security Fundamentals

Although I learned about security during my university days in Germany, I hadn’t practiced it for years. After joining Mercari, I learned about Mercari’s Security Champion Program and saw a great opportunity to brush up my security knowledge and apply it in a real-world environment.
One thing I love about my team at Mercari is the ability to spend part of my time outside the main product development tasks within our team. The Security program fit in perfectly: through online learning and live sessions, I studied with engineers from other teams and dove into topics like web security, mobile security, and even prompt injection.
The concept that stuck most was threat modeling: Threat modeling is a technique to sit together with a group of people and get into the mindset of a hacker to ask “How could i attack the system?”. After collecting various ideas about potential threats, we can estimate their likelihood and potential impact.

Phase 2: Spotting Potential Issues

By applying this mindset as a hacker to my own projects I was able to discover a potential issue within the Help-Center Chat system that was under development during that time. Since Help Center deals with sensitive customer data, security is very important.

To better understand the issue, let me first explain the Chat system. The Chat system consists of three main components: the Chat frontend interface that is used by the customer, the Google Contact Center AI Platform Backend and the Contact Center dashboard.

To make development of connecting the frontend with the backend easy, Google CCaaS (Contact Center as a Service) partner with the company Ujet to provide SDKs: The Web SDK, and the Headless Web SDK. While the Web SDK allows for simple integration with already provided UI / UX, the Headless SDK allows for more customization.

When a customer sends a message in the chat, that message will be sent through the Google Platform to the Customer support agent and displays the message in the customer support dashboard.

While implementing support for clickable links, I realized that when sending a message that includes a html tag through the Headless SDK, the messages were rendered as raw HTML on the agent dashboard rather than being escaped. I then also tried to display a button using the <button> html tag and successfully rendered it in the virtual agent dashboard.

Interestingly, the Web SDK automatically escaped HTML content correctly, but the Headless SDK did not. That inconsistency made me suspicious: this might not just be a harmless display issue—it could be a potential XSS vulnerability.

Phase 3: Discovering and Reproducing the Vulnerability

To further investigate the potential issue with the Web SDK, I used a tool called Burp Suite. Burp is a valuable security testing tool that lets you intercept any kind of application traffic such as a web app or native iOS/Android devices. The intercepted traffic can then be modified within the tool before sending it to the server. A hacker could use a similar tool to change the message to the customer and avoid frontend sanitation.

The idea is to write a message “test” that is transformed into html like this <div onmouseover="alert(document.domain)">hello</div>. When the Customer Support Agent hovers over the message and sees a popup, that means that javascript can be executed.

After investigation the message that is sent to CCaaS looks like this:

TWILSOCK V3.0 481
{"id":"[masked]","method":"message","active_grant":"ip_messaging","payload_type":"application/json;
charset=utf-8","http_request":{"host":"aim.us1.twilio.com","path":"/Client/v2/Services/
[service-id]/Conversations/[masked]/Messages","method":"POST","params":{},
"headers":{"Content-Type":"application/json; charset=utf-8",
"X-Twilio-Mutation-Id":"[masked]"}},"payload_size":69}
{"body":"{\"type\":\"text\",\"content\":\"test\"}","attributes":"{}"}

What we need to change is:

TWILSOCK V3.0 482
{"id":"[masked]","method":"message","active_grant":"ip_messaging","payload_type":"application/json;
charset=utf-8","http_request":{"host":"aim.us1.twilio.com","path":"/Client/v2/Services/[masked]/Conversations/[masked]/Messages","method":"POST","params":{},"headers":{"Content-Type":"application/json; charset=utf-8",
"X-Twilio-Mutation-Id":"[masked]"}},"payload_size":124}
{"body":"{\"type\":\"text\",
\"content\":\"<div onmouseover=\\\"alert(document.domain)\\\">hello</div>\"}","attributes":"{}"}

In addition to the message, the payload_size and the TWILSOCK header needed to be replaced as well. With Burp this is quite simple, you need to select Proxy, enter interception mode and use the match and replace feature to replace the message and payload size.

After this I was able to reproduce the issue and confirm the XSS vulnerability.

Phase 4: Reporting

I initially discovered the issue on March 21st 2025 and got familiar with Burp to reproduce the tool consistently. On March 24th, I wrote a report to Google, initially through the Google Bug hunter program. Unfortunately the response was taking some time, so I decided to directly create a support case within Google Cloud Platform on April 2nd. Then things went fast and the vulnerability was fixed on April 9th 2025: CCaaS Platform Release Notes – April 09 2025.

Conclusion

I am happy that not only was the issue resolved quickly, but also that I could apply my knowledge to prevent potential leaks of private information from real customer interactions.

This experience reminded me how important it is to stay curious. With the increased use of AI generated code and tools, it is even more important now than ever before to deeply inspect every piece of code.

I hope this article encourages you to learn more about security and security tools like Burp Suite! Maybe If you are lucky enough you can earn a reward though programs like Google’s Bug Hunter!

Thank you for reading this blog post and I hope you have learned something new about security.

Tomorrow’s article will be by @hi120ki about LLM Key Servers. Stay tuned!