What is XSS? How to Find Your First Real Bug — WordsByEkta🌿
What is XSS? How to Find Your First Real Bug — Step by Step
This is where reading stops and doing begins. Your first real bug is closer than you think — and it requires no coding, no tools, and no prior experience.
Four Articles In — Now It Gets Real
You know what bug bounty is. You know how the system works. You know which platforms exist and how to open them. You have read real bug reports on Hacktivity. You have a profile on HackerOne.
Now it is time to find something.
XSS is where most beginners find their first real bug. Not because it is the easiest bug in existence — but because it is the most accessible. It requires nothing but your browser, a search box, and the willingness to try something that feels slightly strange. No tools to install. No code to write. No technical background needed.
By the end of this article you will have tried your first XSS lab on a real practice platform — and understood exactly what happened and why.
What Does XSS Actually Stand For?
XSS stands for Cross-Site Scripting. The name is confusing — it sounds like something that crosses between two websites. That is not quite what it means. The "cross-site" part is historical and slightly misleading. What matters is the "scripting" part. XSS is a bug where a website accidentally runs code that you — the tester — put there. Code that the website was never supposed to run.
In plain language: you type something into a search box or a form, the website takes what you typed and shows it back to you on the page — and instead of treating your input as plain text, it treats it as a instruction and runs it. That running of your instruction is the bug.
Imagine you walk into a library and ask the librarian: "Do you have a book called Hello?" The librarian writes "Hello" on a whiteboard so everyone can see the search. That is normal — they are just displaying your words. Now imagine instead you asked for a book called "Ring the fire alarm." And the librarian, without thinking, rang the fire alarm — because they treated your request as an instruction rather than just words. That is XSS. The website treated your input as something to execute, not something to display.
A real XSS bug on a real website could allow an attacker to steal a logged-in user's session, redirect someone to a fake login page, or run code in another user's browser without their knowledge. That is why companies take it seriously and pay bounties for finding it.
Reflected, Stored, and DOM — Simply Explained
There are three main types of XSS. You do not need to master all three before starting. But knowing they exist — and what makes each different — helps you know what you are looking for.
You type something into a search box or URL. The website immediately reflects it back — shows it on the page. If the website does not clean your input before displaying it, your code runs. The effect is instant and visible. This is the type you will try in the lab below — and the most common type found by beginners on real programmes.
You type something into a comment box, a profile field, or a message. The website saves it to its database. Now every user who visits that page loads your code — not just you. This is more dangerous because it affects other users, not just you. It is also harder to find and worth more in bounties.
This type happens entirely in the browser — the server never sees the malicious input at all. It requires understanding how JavaScript handles page content. Do not worry about this type yet. Focus on Reflected XSS first. DOM XSS is a Stage 3 topic.
For now: Focus entirely on Reflected XSS. It is what the lab below tests, it is what beginners find first, and understanding it deeply is more valuable than knowing all three types shallowly.
Before the Lab — Watch This
This video explains what XSS is and how it works visually. Watch it before attempting the lab — it takes about 10 minutes and will make everything that follows much clearer.
Your First XSS Bug — Step by Step on a Real Practice Platform
PortSwigger Web Security Academy is a free platform built specifically for learning web security. It has practice labs — safe, controlled environments where you test for real bugs on fake websites. Nothing you do here affects a real company or real users. It is a practice space designed exactly for this moment.
You do not need to create an account to do the first lab — though creating one (free) lets you track your progress.
-
Go to the lab Open your browser and go to: portswigger.net/web-security/cross-site-scripting/reflected/lab-html-context-nothing-encoded
Or go to portswigger.net/web-security, click Cross-Site Scripting in the left menu, then select Reflected XSS, and choose the first lab listed. -
Click "Access the lab" A new browser tab opens with a fake shopping website. This is your target. It looks like a real website. It is not — it is a safe practice environment.
-
Find the search box Look at the top of the fake website. There is a search box. Click on it.
-
Type a normal word first Type something simple — like "shoes" — and press Enter or click Search. Notice that the website shows your word back to you: "0 search results for shoes." It is reflecting your input back onto the page. This is what makes it potentially vulnerable.
-
Now type the XSS payload Clear the search box. Type exactly this — every character, exactly as written:
-
Press Enter or click Search Watch what happens.
-
A popup appears A small browser alert box appears saying "XSS." Click OK to dismiss it. The lab marks itself as solved.
You just found a real bug.
Not a simulated one. Not a made-up exercise. A real Cross-Site Scripting vulnerability — on a practice target, but using the exact same technique that finds real bugs on real websites. The popup appeared because the website trusted your input and ran it as code instead of displaying it as text. That trust is the vulnerability. You found it.
If the popup did not appear — do not close the tab. Check that you typed the payload exactly, including the angle brackets and the quote marks. Try again. The hint button in the lab is there for a reason — use it. That is not cheating. That is learning.
Why the Popup Appeared — And Why That Matters
When you typed normal text like "shoes" into the search box, the website displayed it safely. But when you typed the script tag, the website took your input and placed it directly into the HTML of the page — without checking whether it was plain text or code. The browser saw the script tag, recognised it as JavaScript, and ran it. The popup was the result of that running code.
On a real website, an attacker would not make a popup appear. They would use that same technique to run code that steals cookies, captures keystrokes, or redirects the user to a fake login page — all invisibly, without the user knowing. That is why this bug matters. That is why companies pay to find it.
The popup is just the proof. What it proves is that you can run code on someone else's website inside someone else's browser. That is significant.
What to Do Next — Try More Labs, Then Real Programmes
One lab is a start. Here is what to do next, in order.
Stay in the Reflected XSS section. Each lab adds a small variation — the website filters some characters, or encodes your input slightly differently. Learning to work around these is how you build real skill. Use hints when you are stuck. Read the solution after completing each one.
Search "XSS" in Hacktivity. Read three publicly disclosed reports. Notice the title format, the steps, the evidence. Copy the structure — not the content — into your own report template.
Go to the HackerOne Directory. Find a small public programme with a web application in scope. Look for a search box. Try the same payload — carefully, within scope only. This is real testing now. Most search boxes on real websites do not have XSS. But some do. And the only way to find out is to look.
Important: Only test on websites that are explicitly in scope on a bug bounty programme. Never test on a random website, even if you think it might be vulnerable. The legal protection of bug bounty comes entirely from the company's permission. Without that permission, testing is not ethical or legal.
How to Write the Report
You tested a search box on an in-scope programme. The popup appeared. You found a real XSS vulnerability. Here is how to report it.
2. Enter the following payload into the search box: <script>alert(1)</script>
3. Press Enter or click Search
4. Observe: a JavaScript alert box appears, confirming script execution
Submit this through the programme's submission form on HackerOne or Bugcrowd. Write calmly and clearly. Do not exaggerate the severity. Let the steps and the evidence speak.
Where This Article Fits — And What Comes After
XSS is Stage 1 of a five-stage journey. You have now completed the foundation — you understand what bug bounty is, how it works, how to use the platforms, and how to find and report your first bug type. That is more than most people who come across this world ever actually learn.
What comes next — IDOR, open redirects, advanced recon, private programme invitations, consistent income — is what the full guide covers, stage by stage, with daily task plans for every week of the journey.
Bug Bounty: From Zero to Expert
Daily task plans · Lab walkthroughs · Report templates · Monetisation from Stage 2 · No coding required
Not ready? Download the free preview first →
- Article 1 — HubIs Bug Bounty Possible for Beginners? — The Full Roadmap
- Article 2What is Bug Bounty? — Complete Beginner's Answer
- Article 3How Does Bug Bounty Work? — The Mechanics
- Article 4How to Actually Get Started — Platforms Step by Step
- Article 5 — You are hereWhat is XSS? Your First Real Bug — Article 5
You read five articles.
You watched the video. You did the lab. The popup appeared.
That moment — small as it seems — is where most people never arrive.
You did.
Comments
Post a Comment