HTTP 400 Bad Request: qué significa y cómo solucionarlo

Qué significa este error y cómo reconocerlo

• Un navegador, cliente de API, monitor de disponibilidad, emisor de webhook u otro cliente HTTP informa de 400 Bad Request.
• La respuesta puede aparecer únicamente para una URL, método HTTP, cadena de consulta, cuerpo de solicitud, conjunto de encabezados o cliente concreto.
• El DNS puede resolver y TLS puede completarse porque el endpoint devolvió una respuesta HTTP.
• El cuerpo de la respuesta puede mostrar una página de error genérica o un mensaje de validación más específico, según el componente que la haya generado.
• Los encabezados de respuesta pueden revelar el estado de la caché, información del proxy o la CDN, el contexto de autenticación, redirecciones o identificadores de solicitud.
• Una solicitud que funcionaba anteriormente puede empezar a devolver 400 después de un despliegue o de un cambio en el enrutamiento, la validación, el proxy o las reglas de seguridad.

Causas principales, ordenadas por probabilidad

1. Detalles de solicitud malformados o no válidos: La URL, la cadena de consulta, los encabezados, las cookies, el método o el cuerpo de la solicitud pueden no cumplir el formato esperado por el endpoint.
2. Reglas de validación o enrutamiento de la aplicación: La aplicación puede rechazar parámetros ausentes, con tipos incorrectos, no compatibles o incoherentes, o la solicitud puede dirigirse a una ruta que no acepta ese método.
3. Gestión del servidor web, proxy inverso, CDN o WAF: Un intermediario puede rechazar la solicitud antes de que llegue a la aplicación debido a reglas de análisis, enrutamiento, filtrado o políticas.
4. Límites de tamaño o formato de la solicitud: El cuerpo, el conjunto de encabezados, la URL, la colección de cookies o un valor cargado pueden superar un límite específico del entorno o utilizar un formato no compatible.
5. Estado de autenticación o sesión relacionado con la solicitud: Una aplicación puede usar 400 para un token no válido, datos de sesión malformados o una solicitud que no puede asociarse con el estado esperado. Otros sistemas usan 401 o 403 para problemas de acceso relacionados, así que confirma el comportamiento en los registros correspondientes.
6. Cambios recientes de configuración o despliegue: Las rutas, la lógica de validación, la autenticación, la caché, el proxy, la CDN o la configuración de seguridad actualizadas pueden cambiar la forma en que se procesa una solicitud conocida.

Cómo solucionarlo

Si eres visitante o consumidor de una API

1. Vuelve a intentar la URL exacta una vez y comprueba si hay errores tipográficos, espacios no deseados, parámetros de consulta truncados o un marcador obsoleto.
2. Si la solicitud requiere una cuenta, inicia sesión mediante el proceso normal del sitio y vuelve a intentarlo. No pegues contraseñas, cookies ni tokens en las solicitudes de soporte.
3. Si utilizas un cliente de API, compara el método HTTP, los parámetros obligatorios, los encabezados, el tipo de contenido y el cuerpo de la solicitud con los requisitos documentados del endpoint.
4. Si falla una solicitud del navegador, prueba la misma acción sin actualizar repetidamente la página. Las solicitudes repetidas pueden añadir carga o interactuar con los límites de frecuencia.
5. Anota la URL o el endpoint, el método, la hora aproximada, el estado de la respuesta y cualquier ID de solicitud que aparezca en la respuesta. Comparte únicamente detalles saneados con el propietario del sitio.
6. Si el error afecta a una sola acción, informa de esa acción y de su comportamiento esperado. Si fallan muchas páginas no relacionadas, informa del alcance general en lugar de asumir que todos los fallos tienen la misma causa.

Si eres propietario o desarrollador del sitio

1. Captura una reproducción mínima. Registra el método HTTP, la URL completa con los valores sensibles eliminados, el estado, los encabezados de respuesta, los encabezados de solicitud relevantes, el tipo de contenido y un cuerpo de solicitud minimizado de forma segura. Confirma que 400 es la respuesta final y no una respuesta intermedia seguida de una redirección.
2. Compara una solicitud que funciona con otra que falla. Comprueba la ruta, el método, los parámetros de consulta, el formato del cuerpo, el tipo de contenido, las cookies, el estado de autenticación, el cliente y el tamaño del payload. Cambia una sola variable relevante cada vez.
3. Identifica la capa que responde. Usa los encabezados de respuesta, el texto del cuerpo, los ID de solicitud y las marcas de tiempo para determinar si la respuesta la produjo la aplicación, el servidor web, el proxy inverso, la CDN o el WAF. Los nombres y valores de los encabezados dependen del entorno, así que considérarlos indicios, no pruebas concluyentes.
4. Inspecciona los registros correspondientes. Busca en la capa identificada y en los componentes adyacentes usando la misma marca de tiempo, ruta, método e identificador de solicitud. Busca errores de análisis, fallos de validación, métodos rechazados, incumplimientos de límites, discrepancias de enrutamiento o coincidencias con reglas de seguridad.
5. Revisa los cambios recientes. Compara los despliegues y cambios de configuración que afecten al enrutamiento, el análisis de solicitudes, la autenticación, la caché, el reenvío del proxy, el comportamiento de la CDN y las reglas del WAF. Comprueba si la ruta debería aceptar la solicitud que falla.
6. Aplica la corrección segura más específica. Corrige el contrato de la solicitud o la ruta o regla concreta que esté rechazando tráfico válido. Evita cambios generales de seguridad, permisos, límites de tamaño o proxy sin autorización y pruebas.
7. Vuelve a probar y comprueba el comportamiento relacionado. Repite la solicitud original y después prueba el método previsto, una solicitud no válida representativa y las rutas relacionadas. Confirma que la corrección no convierta solicitudes malformadas en éxitos no deseados ni rompa las redirecciones, la autenticación, la caché o los controles de seguridad.
8. Conserva las evidencias útiles. Guarda los detalles saneados de la solicitud, las marcas de tiempo, los encabezados relevantes y los registros conforme a tus prácticas habituales de conservación y privacidad.

Prevención y cómo verificar la solución

• Define y documenta los métodos, parámetros, tipos de contenido, requisitos de autenticación y límites de tamaño de solicitud aceptados para las rutas importantes.
• Valida las solicitudes de forma coherente y devuelve, cuando corresponda, un mensaje de error útil que no exponga información sensible.
• Mantén la configuración de enrutamiento, proxy, CDN, autenticación, caché y WAF bajo control de cambios.
• Prueba solicitudes válidas y no válidas representativas después de las versiones de la aplicación o la infraestructura.
• Supervisa las tasas de 400 por ruta, método, cliente y despliegue para distinguir una regresión localizada de un cambio generalizado.
• Conserva los identificadores de solicitud y los registros relevantes durante el tiempo suficiente para relacionar una respuesta con el componente que la produjo.
• Redacta las contraseñas, cookies, valores de autorización, datos personales y secretos de API en los registros y las evidencias de soporte.

Preguntas frecuentes