My First XSS: Two Stored Bugs in Displaybit

// TL;DR

---

The target

Last time I explained what XSS is. This time I want to show you how I found my first XSS vulnerability — on Displaybit, a website that pays users for uploading and sharing images.

If you’ve read the XSS primer, the pattern here will look familiar: user input landing in a page without being neutralised. What made this one special wasn’t the technique. It was that it was mine — the first real bug I ever found and reported.

The first bug: image title

Honestly, this took about two minutes.

I uploaded an image and, instead of a normal title, set the title to a classic test payload:

<script>alert("xss")</script>

Then I saved the image. As soon as I refreshed the page, the script executed — the title field was being stored and rendered straight back into the page without encoding. Stored XSS, first try.

I reported it to Displaybit. They fixed the bug and thanked me.

The second bug: image search

Encouraged, I kept looking — and found a second XSS, this time in Displaybit’s image search.

While viewing one of my images, I noticed a search bar on the page. I dropped the same payload into it:

<script>alert("xss")</script>

…and again, the script executed. The search feature was reflecting input back into the results without sanitising it. I reported this one too, through OpenBugBounty:

Disclosure: https://www.openbugbounty.org/incidents/220844/

Why it matters

Neither of these bugs was complicated. That’s exactly the point — your first finding usually isn’t. XSS is one of the most common web vulnerabilities precisely because developers forget that every place user input is displayed is a place it can be injected: titles, search boxes, comments, profile fields.

I found my first XSS in Displaybit, and my bug hunting career started right here. There are many more techniques and approaches to finding vulnerabilities, and I’ll be covering them in future writeups.

Thanks for reading — happy hacking!