Teaching a Dumb Script to Find XSS

Jun 25, 2025 · 2 min · web , xss , python , tooling

Cross-site scripting is the bug that refuses to die, and the reason is simple: it is not one bug, it is a thousand tiny variations of the same betrayal. The application takes something you typed and puts it back on the page without checking whether what you typed was words or weapons.

xss-probe is my reflected-XSS detector, and the hard part was never finding reflections. The hard part is making a script smart about context, because a payload that works in one place is harmless in another.

This is the part most naive scanners get wrong. When your input shows up in the page, it lands somewhere specific. Maybe inside the HTML body. Maybe inside an attribute, wrapped in quotes. Maybe inside a <script> block where it is already being treated as code. Each of those needs a completely different payload to break out and execute. A scanner that fires the same <script>alert(1)</script> everywhere misses three quarters of the real bugs because it never asked “where did my input actually land?”

So xss-probe looks first. It injects a harmless unique marker, finds where the marker is reflected, works out the context it landed in, and only then picks a payload designed to escape that specific context. It is the difference between a battering ram and a lockpick. The battering ram is louder and works less often.

Tested against DVWA and Juice Shop, because those are built to be abused and nobody calls a lawyer. It catches the obvious cases cleanly, and I document the ones it misses, because a tool that lies about its false negatives is worse than no tool at all.

The lesson that is bigger than XSS: the quality of an attack is mostly the quality of your attention. Look at where your input goes before you decide what to send.

Edit this page on GitHub Last updated: 5/29/2026, 3:36:43 PM