Entradas inesperadas y errores mal manejados

Inyección, explicada para QA

A05:2025 Injection ocurre cuando el sistema toma lo que escribió el usuario y lo ejecuta en vez de tratarlo como texto: como parte de una consulta a la base de datos, de un comando o de la página que ve otra persona.

QA no necesita herramientas de ataque para detectar las señales. Le basta con lo que ya hace en pruebas de borde, sumando algunos valores:

• una comilla simple en un campo de búsqueda o de nombre: si aparece un error de base de datos, el sistema está armando consultas con el texto del usuario;
• caracteres especiales en un comentario o una reseña: si se ven interpretados (en negrita, como enlace, alterando la página) y no como texto, la página está mezclando contenido del usuario con su propio código.

Lo que se espera siempre: que lo escrito se vea tal cual, como texto, y que el sistema no se caiga. Si aparece cualquiera de esas señales, se reporta y lo confirma un especialista. QA no necesita explotarlo para demostrar que es un bug.

La validación vive en el servidor

Un formulario que impide escribir una cantidad negativa está bien, pero no protege nada: cualquiera puede mandar la petición directamente a la API, sin pasar por la pantalla. La prueba:

1. haz la acción en la pantalla y copia la petición desde la pestaña Red;
2. repítela cambiando el valor por uno imposible;
3. lo que se espera es 400 con un mensaje claro; lo que no se espera es 200.

La validación de la pantalla es comodidad para el usuario. La del servidor es la protección.

A10: cuando algo sale mal

La categoría nueva de 2025, A10 Mishandling of Exceptional Conditions, mira algo que QA siempre probó sin ponerle este nombre: qué hace el sistema cuando algo falla. Tres formas de fallar mal:

1. Errores que dicen demasiado. Un 500 que muestra el tipo de error, la ruta de un archivo o la versión de una librería le entrega a un atacante el mapa del sistema. Lo correcto: un mensaje genérico para la persona y el detalle solo en los registros internos.

2. Pantallas que mienten. La pantalla dice "Guardado" y el servidor respondió 500. La persona confía en datos que no existen. Lo correcto: si falla, decir que falló.

3. Fallar abierto. Ante un error al revisar un permiso, el sistema deja pasar en vez de bloquear. Lo correcto es fallar cerrado: si no se pudo verificar, no se permite.

Cómo provocar errores

• mandar peticiones incompletas o con el formato equivocado;
• cortar la conexión a mitad de una operación (las herramientas de desarrollo permiten simularlo);
• repetir dos veces la misma acción muy rápido, como pagar dos veces;
• usar datos que no existen: un pedido borrado, un producto agotado.

Y en cada caso, revisar qué se muestra, qué responde la API y qué quedó guardado.

Automatizarlo

import { test, expect } from '@playwright/test';

test('el login sin datos responde 400 y no muestra detalles internos', async ({ request }) => {
  const respuesta = await request.post('/api/login', { data: {} });
  expect(respuesta.status()).toBe(400);

  const cuerpo = await respuesta.text();
  expect(cuerpo).not.toMatch(/TypeError|stack|\.js:\d+/i);
});