I have the feeling I understand what the problem is here. Next week, I will provide a good explanation of why it does not work as expected. Thanks for the post!
I will only answer on the security questions because this is my expertise at Sonar.
(1) The first thing you need to know is that we make sure our security detection raises as few false positives as possible. For this reason, we detect injection issues like XSS only when the code provides a possibility to the user of your web app to inject data.
In your example, $malware is not injected, it’s a hardcoded value, so the analyzer does not detect it as a source of attacks.
(2) This means that if you want to test for Laravel XSS, you need to do something like this:
Here, data is retrieved from a user of the webapp and then directly set as a response. This is an XSS.
(3) Your example uses Laravel’s templating engine, Blade. In 2021, we decided not to support Blade because it was not the highest-priority framework at the time. We have since started supporting multiple other templating frameworks, just not this one.
Please tell us if this would prevent you from using the product, it would be an important insight for us and a reason to support it
If you want to test this kind of vulnerability without directly paying, you can use https://sonarcloud.io/.
You just need to create a public codebase and try analyzing it (If you want to add private code it needs the paid version)
About Laravel Blade, I tried googling it for alternatives or even competitors and I found nothing. What I suggest is that if you find a linter or some tooling that allows it, you can plug it into SonarQube to aggregate the results in only one location.
In any case, we have great security support for Laravel controllers written in pure PHP I can assure you.
We have prioritized other languages these last few years, so we support templating engines mostly for other languages, such as Thymeleaf or Jinja. This is generally because we react to users’ needs.
If you do not have time to write your use case, please tell me and I will adapt your contribution. While we may not cover every templating engine available yet, we strive to expand our support to meet our users’ needs, so your input will be very valuable.
Plus, we are going to work more on PHP security for a bit in 2025, and if we gain traction from the PHP community toward PHP’s templating engines, it will be deemed legitimate, and we will definitely work on it
Technically, SonarQube will do an analysis with them in it, so it will “support” them, but no detection rule supports them.
I cannot give a comprehensive list of the detection rules supporting all templating frameworks. This information is too scattered across our thousands of rules