PostgreSQL
Prevención de SQL injection mediante parámetros, whitelists para identificadores y validación de entradas, sin construir consultas con concatenación insegura.
La parametrización separa valores de la estructura SQL. Protege strings, números y fechas, pero no convierte nombres de tabla, columnas, operadores ni direcciones de orden en parámetros.
Patrón seguro:
await client.query(
'SELECT id, name FROM products WHERE business_id = $1 AND name = $2',
[businessId, name],
);El servidor recibe SQL y valores por canales separados. El input no puede cerrar una comilla y convertirse en código.
const sql = `SELECT * FROM users WHERE email = '${email}'`;Input:
' OR true --modifica la estructura. Escapar manualmente no es una estrategia confiable.
No puede parametrizarse directamente:
ASC/DESC.const columns = {
createdAt: 'created_at',
total: 'total_amount',
} as const;
const directions = { asc: 'ASC', desc: 'DESC' } as const;
const column = columns[input.sortBy];
const direction = directions[input.direction];
if (!column || !direction) throw new Error('Invalid sort');
const sql = `
SELECT id, created_at, total_amount
FROM orders
WHERE business_id = $1
ORDER BY ${column} ${direction}, id ${direction}
LIMIT $2
`;Solo se interpolan fragmentos definidos por el código.
Evita construir:
`WHERE id IN (${ids.join(',')})`Usa arrays:
WHERE id = ANY($1::bigint[])Define semántica para array vacío.
Parámetros previenen SQL injection, pero % y _ siguen siendo wildcards del lenguaje LIKE:
WHERE name ILIKE '%' || $1 || '%'Si buscas texto literal, escapa esos caracteres según un ESCAPE definido. Parametrización y escaping de patrones resuelven problemas distintos.
Aunque sean parámetros, el usuario todavía controla un pequeño lenguaje que puede ser costoso o producir errores. Prefiere constructores seguros:
websearch_to_tsquery frente a to_tsquery libre.La ausencia de injection no garantiza resistencia a abuso de recursos.
EXECUTE format('SELECT count(*) FROM %I.%I', p_schema, p_table)
INTO result;Valores:
EXECUTE 'SELECT * FROM app.orders WHERE id = $1'
USING p_id;%I cita identifiers, USING parametriza valores. Aun así, valida que el identifier pertenezca a un conjunto permitido.
Reducen concatenación accidental, pero no eliminan injection:
orderByRaw.Revisa el SQL generado y limita escape hatches.
Input peligroso puede almacenarse como dato y más tarde concatenarse en otro SQL administrativo. La validación al ingresar no sustituye parametrizar en cada punto de ejecución.
Si ocurre injection, el impacto depende del role:
runtime sin DDL ni acceso a otras schemas
→ daño limitado
runtime owner/superuser
→ compromiso amplioDefense in depth: parámetros + allowlists + roles mínimos + timeouts + auditoría.
No devuelvas SQL, stack, schema o detalles de constraints al cliente no confiable. Registra contexto seguro internamente con query normalizada, no passwords ni valores sensibles.
Algunos drivers desactivan múltiples statements o utilizan extended protocol. No dependas de eso como defensa principal. Una condición inyectada dentro de un único SELECT ya puede exfiltrar información.
NULL necesita cast para inferir tipo.$1.ORDER BY $1 no elige columna?$1 representa un valor constante, no un identifier.= ANY($1::type[]) o placeholders generados de forma segura.Conexiones, sesiones y pooling administra el recurso más limitado entre aplicación y base.