Report context
I submitted this finding to Snapchat's HackerOne program on June 8, 2023. It affected the search feature on newsroom.snap.com and required no authentication. The team fixed the issue, and the report was publicly disclosed on August 14, 2023.
Note: this article documents a historical issue that has already been fixed. Only test systems you own or have explicit permission to assess.
The entry point
The search route received text through the q parameter. That value was displayed again in the interface, but the browser did not handle it only as text: it interpreted HTML tags included in the query.
https://newsroom.snap.com/es-ES/search?q=<controlled_marker>
The distinction matters. Reflecting characters as text only changes what the user reads. Inserting them into the DOM as HTML allows links to be created, styles to be changed and elements to be placed over legitimate content.
Proof of concept
I first confirmed reflection using a recognizable marker. I then used a styled link to demonstrate that injected content could occupy a prominent area of the page. This version uses a reserved domain and a neutral message:
<a href="https://example.invalid"
style="position:absolute; padding:40px; z-index:1000">
Demonstration link
</a>
The original payload was URL encoded. When the URL was opened, the browser constructed the <a> element inside the results page.

Impact, without overstating it
The proof demonstrated HTML injection, not JavaScript execution. That is why I did not present it as XSS. The confirmed impact was the ability to alter the visual composition, display a convincing message and direct a user elsewhere from a URL beginning on a genuine Snapchat domain.
This context could support phishing or visual impersonation. Trust in the legitimate domain made the lure more credible, although final impact still depended on a victim opening the link and interacting with the injected content.
How to fix it
- Insert the search term with APIs that treat it as text, not HTML.
- Apply output encoding for the context in which the value is rendered.
- Avoid functions such as
innerHTMLwhen displaying untrusted input. - Add regression tests covering tags, attributes and special characters.
- Use a Content Security Policy as an additional defense, not a substitute for correct escaping.
What I took away from the case
A search box may look like a simple surface, but it combines input, rendering and visual trust. The key was to separate what had been demonstrated from what remained hypothetical: there was control over HTML and styling, but no evidence of script execution.
That precise scope made the report easy to reproduce and explained the impact without exaggeration.
View the original public report on HackerOne ↗