Fix SQL Injection (Legacy & Modern) in Gatsby

Gatsby's static nature doesn't make it immune. SQL Injection (SQLi) manifests in Gatsby Functions (API routes) and custom 'gatsby-node.js' source plugins that interact with external databases. If you're concatenating strings to build queries in your serverless functions, you're vulnerable. Modern Gatsby apps must treat the data layer as a hostile environment.

The Vulnerable Pattern

import sqlite3 from 'sqlite3';
export default function handler(req, res) {
const db = new sqlite3.Database(’./data.db’);
// CRITICAL VULNERABILITY: Direct string interpolation of user input
const query = SELECT * FROM users WHERE id = '${req.query.id}';
db.all(query, (err, rows) => {
if (err) return res.status(500).send(err);
res.status(200).json(rows);
});
}

The Secure Implementation

The legacy approach failed by allowing the 'id' parameter to break out of the string literal via a single quote (e.g., ?id=1' OR '1'='1). The modern fix utilizes Parameterized Queries. In this pattern, the database driver sends the query template and the data separately. The database engine treats the parameters strictly as data, never as executable SQL code. For Gatsby developers using ORMs like Prisma or Knex in Gatsby Functions, these libraries use parameterization by default, but raw 'db.raw()' calls must still be handled with explicit parameter arrays to prevent exploitation.

import sqlite3 from 'sqlite3';
export default function handler(req, res) {
const db = new sqlite3.Database(’./data.db’);
// SECURE: Using Parameterized Queries (Prepared Statements)
const query = ‘SELECT * FROM users WHERE id = ?’;
const params = [req.query.id];
db.all(query, params, (err, rows) => {
if (err) return res.status(500).send(err);
res.status(200).json(rows);
});
}