DEV Community

Cover image for Finding XSS before attackers do: auditing your Laravel app with Kali
ArmelDev
ArmelDev

Posted on Originally published at armeldev.xyz

Finding XSS before attackers do: auditing your Laravel app with Kali

#softwaredevelopment #security #vulnerability #laravel

Your application passes all its tests. Forms validate data, Blade views escape what they display. Then one day, a forgotten search field echoes the typed text back into the page, unfiltered. Someone only had to try.

Attackers don't have access to our code. They explore the application from the outside, page by page, and test every parameter. In late October, Kali Linux 2026.3 added two tools that let you do the same on your own applications: katana and dalfox (BleepingComputer).

These tools are only to be used on applications you are responsible for, or with written authorization.

An attacker starts by mapping

Katana is a site crawler. It follows links, reads JavaScript and lists every URL and parameter it finds. It's the map of what a visitor can reach.

katana -u https://staging.example.com -d 3 -o urls.txt
Enter fullscreen mode Exit fullscreen mode

This list often holds surprises: an old route never removed, a reachable admin page, a forgotten parameter.

dalfox tests every parameter for you

Dalfox takes those URLs and injects, into each parameter, payloads designed to reveal an XSS flaw. It reports the ones that come back into the page without being neutralized.

cat urls.txt | dalfox pipe -o results.txt
Enter fullscreen mode Exit fullscreen mode

You can also target a single page:

dalfox url "https://staging.example.com/search?q=test"
Enter fullscreen mode Exit fullscreen mode

No need to install all of Kali: both tools are in its repositories and in the official Docker image, which 2026.3 also makes easy to build.

In Laravel, flaws almost always come from the same places

Blade escapes everything that goes through {{ }} by default. XSS appears when you step outside that frame:

  • raw output with {!! !!} , often added for HTML coming from a text editor;
  • data injected into inline JavaScript, instead of going through @json or Js::from ;
  • HTML built client-side with innerHTML from API data;
  • attributes like href filled with a user-supplied URL ( javascript: ).

When rich HTML really has to be displayed, it must be cleaned with a dedicated library before it is stored or displayed.

The right time is before production

These tools send many requests and deliberately malicious data. So you run them on a staging environment, never on production with real data.

A pass of katana and dalfox before each major release takes a few minutes. That's little, compared with the time spent fixing a flaw someone else found.

Testing your application like an attacker takes away their element of surprise.

And you, have you ever looked at your application through the eyes of someone trying to break it?

Top comments (0)