Approval Team insists that XSS Vulnerability exists because of Admin Panel settings.

We’re currently in the phase of launching a new product, It has been soft rejected due to “XSS Vulnerabilities”

Even though these “vulnerabilities” are due to some admin panel fields such as Ad Codes. You obviously cannot sanitize Ad Code fields as some ad networks provide you with script tags to insert.

Now obviously, this would be a catastrophic issue If it was on the user end, and the user was somehow able to print their desired HTML / Run scripts. But it’s only on the admin side. So does it really even count as a vulnerability?

Because, why would the admin need to inject some malicious code into their OWN site to attack their OWN users whose data they already have in plain sight (in the database)

This confused me a little bit so just need thoughts and opinions on this.

Best Regards

function sanitize_trusted($content) {
    echo $content;
}

And then anywhere you send raw HTML from trusted user input:

echo sanitize_trusted($adBannerHTML);

That’s how I “fixed” this issue :sweat_smile:

Do a global search in your project for echo $_ - if you find any hits then this might be what the reviewer is complaining about.

2 Likes

Excellent advice from @baileyherbert for you @BitFlan . Hope it works out well.

2 Likes