使用innerHTML插入服务器HTML的JS脚本结合当前PHP后端配置是否存在XSS漏洞？

Hey there! Let's break down your XSS risk question step by step based on the code you shared.

First off, let's quickly clarify the core of XSS: when untrusted content that hasn't been properly sanitized gets inserted into your page, and the browser parses it as executable code (like scripts, event handlers, or malicious HTML), that's when an XSS attack can occur. Now let's dig into your setup:

1. What's Safe, and What's Not? #

Your Search Parameter Sanitization Works (For XSS) #

You're using htmlspecialchars($search, ENT_QUOTES, "UTF-8") to clean the search input, which is the right move here. This function converts HTML special characters (like <, >, ", and ') into HTML entities—so if someone tries to input something malicious like <script>alert('steal data')</script>, it gets turned into <script>alert('steal data')</script>. When this gets inserted into your page via innerHTML, it'll show up as plain text instead of running as a script. So the search parameter itself isn't a source of XSS risk.

The Hidden Risk: Outputting Unsantized Database Content #

The problem lies in how you're outputting data from your database in the get_characters function. You're directly echoing $character_name (from the personnage table) into your HTML without any sanitization—like in this line:

<h2><a> $character_name </a></h2>

If a user ever created a character with a name that includes malicious HTML or JavaScript (say, <img src=x onerror=alert(document.cookie)>), and that content was stored raw in the database (without being sanitized first), then when you echo it out and insert it into the page via innerHTML, the browser will parse that malicious code and run it. That's a classic stored XSS vulnerability.

For example: If a character's name is <script>console.log(document.cookie)</script>, your current code would insert that script directly into the page, and it would execute when the page loads.

A Quick Side Note: SQL Injection Risk #

While you asked about XSS, it's worth mentioning that your SQL query has a SQL injection risk. Even though you're using htmlspecialchars on the search parameter, you're still directly concatenating it into your SQL string. Instead, use parameterized queries (prepared statements) to keep your database safe:

// Replace your current query with this
$get_characters = $dbh->prepare("SELECT * FROM `personnage` WHERE `id_utilisateur` = ? AND `nom` LIKE ?");
$get_characters->execute([$account_id, "%{$sanitized_search}%"]);

2. How to Fix the XSS Vulnerability #

To lock down your code against XSS, you need to sanitize all user-controlled content when you output it to HTML. Here's what to do:

For every dynamic value you echo into your HTML (like $character_name, and even $character_id if it could ever be a string), wrap it with htmlspecialchars:

// Sanitize the character name before outputting
$safe_character_name = htmlspecialchars($character["nom"], ENT_QUOTES, "UTF-8");
// Use the sanitized version in your HTML
echo("<h2><a> $safe_character_name </a></h2>");

This ensures that even if malicious content exists in your database, it gets converted to harmless HTML entities before being sent to the browser.

As an extra layer of safety, you can also sanitize user input before storing it in the database (like when a user creates a character). But remember: output sanitization is the critical final line of defense, since databases can sometimes receive unsanitized data from other sources.

Final Verdict #

Your search parameter handling is safe from XSS, but your code has a stored XSS vulnerability because you're outputting unsanitized character names from your database. Adding htmlspecialchars to all dynamic content when you echo it will fix this risk entirely.

内容的提问来源于stack exchange，提问作者frederic chippaux