Back to scan results
What this check probes
The scanner tests the public HTTPS page with four common parameter names: id, item, page, and q. For each parameter it first requests a clean value, then repeats the request with single-quote and double-quote suffixes.
It looks for database error signatures associated with MySQL, SQL Server, PostgreSQL, Oracle, and SQLite that appear only after the probe. A new HTTP 5xx response without a recognizable database message is reported as a warning for manual review.
This is deliberately a low-impact public check. It does not send data-changing SQL, authentication-bypass strings, UNION queries, or time-delay payloads.
Why this matters for PCI DSS
SQL injection can let an attacker read, modify, or delete application data, including cardholder data and credentials. PCI DSS requires public-facing applications to be protected against common software attacks and requires secure coding techniques for injection flaws.
A pass only means the limited public probes did not expose an obvious error-based weakness. Authenticated pages, POST bodies, JSON APIs, stored procedures, and unlinked endpoints require authenticated application testing or a formal penetration test.
How to fix it
Use parameterized queries everywhere. Never concatenate request data into SQL text:
// BAD
var sql = "SELECT * FROM Products WHERE Id = " + Request.QueryString["id"];
// GOOD (.NET Framework / ADO.NET)
using (var cmd = new SqlCommand("SELECT * FROM Products WHERE Id = @id", connection))
{
cmd.Parameters.Add("@id", SqlDbType.Int).Value = productId;
using (var reader = cmd.ExecuteReader())
{
// Read the result.
}
}
Validate input against the expected type, give the application's database account only the permissions it needs, and show generic error pages in production. A web application firewall can add defense in depth, but it does not replace parameterized queries.