In partnership with

🎯 Week 5: Cross-Site Scripting (XSS)

Break the Web: Part 5 of 8

Welcome back to Offensive Tuesday.

Hey 👋

Last week you injected SQL and commands directly into servers. You bypassed logins, dumped databases, and executed system commands. If you missed it, catch up here 👉

• Week 1: Recon & Attack Surface

• Week 2: Authentication & Session Management

• Week 3: Access Control & IDOR

• Week 4: Injection (SQL & Command)

This week? We're hijacking browsers.

Here's what most people don't understand — the browser trusts the website completely. If you can inject JavaScript into a page, you own every user who visits it.

Their cookies? Yours.
Their keystrokes? Captured.
Their session? Hijacked.
Their bank account? One click away.

You're not attacking the server anymore. You're attacking everyone who uses it.

This is Cross-Site Scripting (XSS) — the vulnerability behind some of the biggest data breaches in history. MySpace worm that infected a million users in 24 hours? XSS. British Airways breach that stole 380,000 credit cards? XSS. Countless session hijackings and account takeovers? You guessed it.

Today you're learning how to turn innocent web pages into attack platforms.

Let's weaponize some JavaScript. ⚡

⚡Starting a business in 2026? Only AI is not enough…

The Future of Shopping? AI + Actual Humans.

AI has changed how consumers shop by speeding up research. But one thing hasn’t changed: shoppers still trust people more than AI.

Levanta’s new Affiliate 3.0 Consumer Report reveals a major shift in how shoppers blend AI tools with human influence. Consumers use AI to explore options, but when it comes time to buy, they still turn to creators, communities, and real experiences to validate their decisions.

The data shows:

• Only 10% of shoppers buy through AI-recommended links

• 87% discover products through creators, blogs, or communities they trust

• Human sources like reviews and creators rank higher in trust than AI recommendations

The most effective brands are combining AI discovery with authentic human influence to drive measurable conversions.

Affiliate marketing isn’t being replaced by AI, it’s being amplified by it.

Download the full report to see what this means for your brand.

🧠 What is XSS?

XSS happens when an attacker injects malicious scripts into web pages viewed by other users.

Here's the flow:

1. You find where the website displays user input (search box, comment, profile)

2. You inject JavaScript code instead of normal text

3. Website doesn't sanitize it

4. Website serves your malicious script to other users

5. Their browsers execute your code

6. You steal their data, hijack sessions, or take over accounts

The key difference from SQL injection: You're not attacking the server. You're attacking the users.

Every victim's browser becomes your puppet.

🎭 The Three Types of XSS

Reflected XSS — Instant Attack

Your payload is in the URL. Victim clicks your link. Script executes immediately.

Think of it like this: You send someone a link to search for "laptops" but you sneak JavaScript into the search term. They click. The website reflects your search back to them. Your code runs in their browser.

Example URL:

http://shop.com/search?q=<script>alert('XSS')</script>

Real example: Victim gets an email saying "Check out these deals!" with a link. Link contains hidden JavaScript. They click. Session stolen.

Use case: Phishing emails, malicious links, social engineering attacks

Stored XSS — Time Bomb

Your payload gets saved in the database. Every user who views that page gets attacked automatically.

You post a comment with hidden JavaScript. The site stores it. Now everyone who reads that comment section executes your code. You don't need to send links anymore. The website does your work for you.

Real example: You leave a "product review" on an e-commerce site. Hidden in your review is code that steals cookies. Every shopper who reads reviews? Compromised.

Use case: Forum posts, user profiles, comment sections, reviews, guestbooks

Why it's the most dangerous: One injection = unlimited victims. Set it and forget it.

DOM-Based XSS — Client-Side Chaos

The vulnerability exists in JavaScript itself, not the server code.

The page's own JavaScript reads something (like the URL) and unsafely inserts it into the page. The server never sees your payload. Web Application Firewalls can't block it.

Real example: A single-page app reads the URL fragment (everything after the #) and displays it on the page without checking what's in it. You craft a malicious URL. Victim clicks. Their own browser executes your code.

Use case: Single-page apps, JavaScript-heavy sites, modern frameworks like React/Angular/Vue

🔧 The XSS Attack Process

Step 1: Find Input Points

Look everywhere users can submit data:

✅ Search boxes
✅ Comment sections
✅ Contact forms
✅ URL parameters
✅ User profiles (name, bio, location)
✅ File upload names
✅ HTTP headers (User-Agent, Referer)
✅ Chat features
✅ Review sections
✅ Error messages ✅ Markdown editors

Your mantra: If it displays user input, test it.

Pro tip: The weirdest places often have the weakest protections. File upload filename? Test it. "Report a bug" form? Test it. Password reset error message? Test it.

Step 2: Test for Vulnerabilities

Start dead simple. Type this into every input field you find:

<script>alert('XSS')</script>

Does a popup appear? Congrats, you found XSS.

But modern sites usually block script tags. So you need alternatives.

Try these payloads instead (full list at PayloadsAllTheThings and PortSwigger's XSS cheat sheet):

• Image tags with error events

• SVG tags with onload events

• Body tags with onload

• Input tags with autofocus

The goal is simple: get JavaScript to execute. If you see alert() pop up, you've proven the vulnerability.

Pro tip: Use alert() for testing only. In real attacks, you're not showing popups — you're stealing cookies and sessions silently.

Step 3: Bypass Filters

Sites try to block XSS. Here's how attackers get around them:

Mix uppercase and lowercase — Filters looking for <script> might miss <ScRiPt>

Use encoding — Turn characters into HTML entities or URL encoding

Try different tags — If <script> is blocked, try <img>, <svg>, <iframe>, <body>, <input>

Use event handlers — onerror, onload, onfocus, onmouseover

Double encoding — Encode your payload twice

JavaScript protocol — javascript:alert(1) in href attributes

Template literals and backticks — Bypasses some WAFs

Don't memorize these. Use the cheat sheets: PayloadsAllTheThings bypass section and PortSwigger's filter evasion guide. There are literally thousands of bypass techniques documented.

The game is simple: keep trying variations until something works.

Step 4: Weaponize Your Payload

alert() proves it works. But real attackers aren't showing popups. They're doing this:

Cookie theft — Send the victim's cookies to your server (full payloads here)

Session hijacking — Steal their authentication tokens (examples here)

Keylogging — Record every keystroke on that page (payload examples)

Phishing — Inject a fake login form over the real page (techniques here)

Credential harvesting — Create a convincing "Your session expired, please log in again" prompt

BeEF framework — Hook the victim's browser for complete remote control (setup guide) - screenshots, keylogging, webcam access, network pivoting

Cryptocurrency miners — Use their CPU to mine coins

Defacement — Change the page content

Admin actions — If the victim is logged in as admin, perform admin actions silently

The scariest part? All of this happens invisibly. The victim sees a normal webpage. Behind the scenes, you're owning their session.

Check out PayloadsAllTheThings and PortSwigger's resources above for full working examples. Don't reinvent the wheel — use battle-tested payloads.

Step 5: Deliver the Attack

For Reflected XSS:

Craft your malicious URL. Shorten it with bit.ly so it doesn't look suspicious. Then:

• Send via email ("Check out this cool feature!")

• Post on Discord, Slack, Reddit

• Send in SMS/WhatsApp messages

• Post in forums with "Check this bug I found"

• Use in phishing campaigns

Social engineering is key. Make people want to click.

For Stored XSS:

Inject once. Walk away. Every visitor gets attacked automatically.

Post your payload as:

• A forum comment

• A product review

• A profile bio

• A chat message

• A support ticket

The website becomes your distribution network.

For DOM XSS:

Target JavaScript-heavy apps. Your payload never touches the server, so WAFs can't see it. Perfect for bypassing security.

🎯 Real-World XSS Hunting

Where XSS hides in 2025:

🔍 Modern JavaScript frameworks — React, Vue, Angular apps with dangerous functions
🔍 User-generated content platforms — Social networks, forums, review sites
🔍 Search functionality — Query parameters reflected in results
🔍 Error messages — "No results found for [your input here]"
🔍 Rich text editors — Markdown, WYSIWYG editors
🔍 Email clients — Webmail rendering HTML emails
🔍 Admin panels — Lower security, higher privileges = bigger payout
🔍 File upload features — Filename gets displayed without sanitization 🔍 URL shorteners — Original URL displayed on preview page 🔍 Translation features — Translated text rendered without encoding

Bug bounty pro tip: Look for XSS in features developers just launched. New code = less testing = more bugs. Check the changelog, then hunt those fresh endpoints.

🛡️ Why XSS is So Dangerous

Here's the brutal truth about XSS:

It bypasses basically everything:

❌ Same-Origin Policy? Doesn't matter. Your script runs in the victim's origin.
❌ HTTPS? Doesn't matter. The malicious script is served over the same secure connection.
❌ Strong passwords? Doesn't matter. You're stealing the session after they log in.
❌ 2FA? Doesn't matter. You hijack the authenticated session.
❌ CORS protections? Doesn't matter. You're already inside their origin.

XSS turns the website itself into your attack tool. The victim trusts the website. The website executes your code. Game over.

🛠️ Essential XSS Tools

Testing & Exploitation:

XSStrike — Automated XSS scanner with smart payload generation — Get it here

Burp Suite — Industry standard for manual XSS testing — Download

OWASP ZAP — Free alternative to Burp — Download

dalfox — Fast, powerful XSS scanner — Get it here

XSSer — Automatic XSS testing framework — Get it here

Browser Developer Tools — Built-in, inspect how the page handles your input

Payload Generation & Exploitation:

BeEF (Browser Exploitation Framework) — Hook browsers and control them remotely — Official site

XSS Polyglots — One payload that works in multiple contexts — Get them here

Payload Collections:

PayloadsAllTheThings - XSS Section — Massive collection of XSS payloads and bypasses — Browse here

PortSwigger XSS Cheat Sheet — Comprehensive payload reference with interactive examples — View here

XSS Payload List — Curated collection of working payloads — Get it here

Awesome XSS — Curated list of XSS resources — Check it out

📚 Learning Resources

Interactive Labs:

PortSwigger XSS Labs — Free hands-on practice with progressive difficulty — Start here

OWASP WebGoat — Practice XSS in a safe environment — Try it

HackTheBox — Real vulnerable machines with XSS challenges — Join here

TryHackMe XSS Room — Guided XSS learning path — Start learning

Google XSS Game — Learn XSS by exploiting intentionally vulnerable pages — Play here

Deep Dives:

OWASP XSS Guide — Complete reference documentation — Read here

PortSwigger XSS Guide — Comprehensive tutorial series — Learn here

Excess XSS — In-depth XSS tutorial — Read it

The Tangled Web — Book by Michal Zalewski, Chapter on browser security

HackerOne XSS Reports — Learn from actual disclosed bugs — Browse reports

That's Week 5. ⚡

Tomorrow (Wednesday): How to defend against XSS and write secure frontend code.

Next Tuesday (Week 6): File Uploads & Remote Code Execution — we're uploading shells and taking over servers.

See you then.

P.S. Got questions? Reply to this email. I read everything.