Home / Knowledge hub / Self-XSS
Knowledge hub
Self-XSS
Tricking a person into pasting attacker code into their own browser console.
What it means
Self-XSS is a social engineering trick. The attacker persuades a person to paste or type code into their own browser, usually the developer console, with a promise such as a free feature or a hidden tool. The code then runs in that person's signed-in session.
Unlike real cross-site scripting, nothing in the application delivers the code. The victim does it themselves, which is why many bug programmes treat it as out of scope on its own.
Why it matters
The result can still be an account takeover. Script run in the console can read the page, act as the person and send data to the attacker. For a business, that means support cases from users who lost accounts, with no flaw in your code to point at.
It also becomes serious when combined with a real bug. A weakness that lets an attacker put content into someone else's session can turn a harmless-looking self-XSS into a genuine, delivered attack.
How it shows up
You see it in scam messages and videos that tell people to open the console and paste a line. Some applications also have fields, such as a profile or custom CSS box, where a person can enter script that then runs for them.
Browsers have added friction, such as a console warning and a need to type a phrase before pasting. Check your application for fields that run user-entered code, add a clear console warning, keep a strict content security policy, and check whether the same field can be reached by someone else through login CSRF or a shared link.
Questions people ask
Self-XSS, answered
Is self-XSS a vulnerability?
On its own it usually requires the victim's own action, so many programmes exclude it. It becomes a real vulnerability when someone else can cause the code to run in the victim's session without their help.
That is why it is worth testing, not ignoring.
How is it different from stored or reflected XSS?
With stored and reflected XSS, your application delivers the attacker's script to a victim. With self-XSS, the victim pastes it.
The impact inside the session is similar.
How do we protect users from it?
Show a console warning that explains the danger, keep a strict content security policy, and avoid features that execute user-entered code. Teach support staff to recognise the scam.
Browsers also warn before pasting into the console.
Can self-XSS be chained into something worse?
Yes. If an attacker can place the payload into a victim's account or session, for example through a login CSRF flaw, the victim never has to paste anything.
Always ask who else can reach the field.
Does a content security policy stop it?
A strict policy blocks many inline scripts, but code typed into the console runs outside normal page loading and is not stopped by it. Browser console protections and user awareness do the work there.
The policy still limits what injected code can load.
Sources
Where this comes from
Related
Terms that sit next to this one
XSS
An attacker's script running in your pages, in your customers' sessions.
Stored XSS
Malicious script saved by your app and then served to other people who view it.
Reflected XSS
A script in a link that your page echoes straight back into the response.
DOM-based XSS
Script injection that happens in the browser's own code, not in the server's response.
Social engineering
Manipulating people, not software, into giving up access or information.
Who else can reach that field?
A harmless-looking input can become a delivered attack once it is chained with another flaw. We find vulnerabilities in web apps and prove each by exploiting it. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.