DynamoDB Excepción de firma incompleta

TL;DR: La firma AWS Firma Versión 4 de la solicitud estaba incompleta o no cumplía con AWS estándarrds, por lo que DynamoDB la rechazó antes de autenticarse. Si utiliza un AWS SDK, la firma es automática; esto casi siempre significa una solicitud hecha a mano o un proxy/puerta de enlace que destrozó el encabezado Authorization después de firmar. Deje que SDK firme y asegúrese de que nada reescriba la solicitud en tránsito.

Qué significa

IncompleteSignatureException: The request signature does not conform to AWS standards.

AWS firma cada solicitud con SigV4. Esta excepción significa que la firma estaba presente pero malformada o le faltaban componentes requeridos — una cabecera Authorization incorrecta, una cabecera firmada faltante, o un desajuste de la solicitud canónica. Es un HTTP 400, del lado del cliente, y no reintentable tal cual: la firma debe corregirse.

Por qué ocurre

Firma hecha a mano — estás construyendo la firma SigV4 tú mismo (no a través de un SDK) y la solicitud canónica, la lista de cabeceras firmadas, o la cabecera Authorization son incorrectas.
Una cabecera Authorization malformada — los disparadores documentados son una cabecera vacía, un parámetro Credential o Signature faltante, una cabecera que no empieza con el nombre del algoritmo (AWS4-HMAC-SHA256), o un par clave=valor sin signo de igual.
Un proxy o API gateway reescribió la solicitud — mutar la cabecera Authorization (u otras partes firmadas) después de que el SDK firmara hace que la cabecera que AWS recibe difiera de la que enviaste.
Cabeceras editadas manualmente — añadir/quitar cabeceras después de firmar, o reordenar la cadena de consulta, rompe la solicitud canónica.

Cómo solucionarlo

Usa un AWS SDK oficial y deja que firme la solicitud. Los SDK implementan SigV4 correctamente por ti — la solución para casi todas las ocurrencias es dejar de firmar a mano.
No mutes la solicitud después de firmar — si hay un proxy/gateway delante, asegúrate de que no añada, elimine ni reordene cabeceras ni cambie el cuerpo/ruta. Firma en el borde que realmente envía la solicitud.
Comprueba si la cabecera Authorization cambió en tránsito — el diagnóstico documentado de AWS: calcula un hash SHA-256 de la cabecera que enviaste, codifícalo en Base64, y compáralo con el hash que algunos mensajes de IncompleteSignatureException incluyen. Si difieren, algo entre tu cliente y AWS modificó la cabecera.
Si debes firmar manualmente, sigue exactamente el proceso de firma SigV4 de AWS — la solicitud canónica, la cadena a firmar, la derivación de la clave de firma, y la cabecera Authorization (algoritmo, Credential=, SignedHeaders=, Signature=) deben coincidir todos. Verifica contra una solicitud SDK conocida como buena.

Una clave secreta incorrecta o truncada es un fallo distinto: produce una firma completa que no coincide, apareciendo como "signature we calculated does not match" en lugar de este error. Del mismo modo, un reloj de máquina desfasado aparece como Signature expired, no como una firma incompleta.

DynoTable + Local

DynoTable usa la ruta de firma del AWS SDK — nada de SigV4 hecho a mano — así que esta clase de error no aparece en uso normal. Si tu aplicación la encuentra mientras DynoTable funciona, compara los perfiles: Ajustes → Perfiles → Test Connection con las mismas claves que carga tu aplicación.

Para Local, credenciales ficticias en un perfil con endpoint http://localhost:8000 saltan la firma por completo. Consulta Conectar a AWS e Instalar. Una vez resueltas las credenciales, lanza una consulta de prueba en el Query Builder.

Fuentes

Error handling with DynamoDB — IncompleteSignatureException (verificado 2026-07-13)
Troubleshoot Signature Version 4 signing (verificado 2026-07-13)

FAQ

¿Qué causa una IncompleteSignatureException? La firma AWS SigV4 de la solicitud estaba malformada o le faltaban partes requeridas — una cabecera Authorization vacía o malformada, un parámetro Credential o Signature faltante, o un par clave=valor sin signo de igual. Con un AWS SDK la firma es automática, así que normalmente significa una firma construida a mano o un proxy que alteró la solicitud después de firmar.

¿En qué se diferencia de UnrecognizedClientException? IncompleteSignatureException significa que la firma en sí estaba malformada. UnrecognizedClientException ("security token is invalid") significa que la firma estaba bien formada pero las credenciales detrás no fueron aceptadas.

Reproducirlo

Envía una cabecera Authorization que esté presente pero que no se pueda analizar como SigV4:

import requests
requests.post(
    'https://dynamodb.us-east-1.amazonaws.com',
    headers={
        'X-Amz-Target': 'DynamoDB_20120810.ListTables',
        'Content-Type': 'application/x-amz-json-1.0',
        'Authorization': 'AWS4-HMAC-SHA256 this-is-not-a-valid-credential-scope',
    },
    data='{}',
)

Salida real:

IncompleteSignatureException: Invalid key=value pair (missing equal-sign) in Authorization header (hashed with SHA-256 and encoded with Base64): 'nmoNS1XQjeE7XjC3Nzhi4KfIKrQZsBTlcf+/muyMgDs='.
HTTP 400

La cadena Base64 del final es un hash de tu propia cabecera, así que cambia en cada petición — no hagas coincidencias contra ella. Lo que el mensaje te está diciendo es estructural: AWS pudo leer el algoritmo, pero no los pares Credential=/SignedHeaders=/Signature= que van después. Eso apunta a cómo se ensambló la cabecera, y por eso esto casi siempre viene de una firma hecha a mano y no de un SDK.

Errores relacionados

The request signature we calculated does not match — una firma completa pero incorrecta (clave secreta o canonicalización erróneas).
The security token included in the request is invalid — firma bien formada, credenciales incorrectas.
The security token included in the request is expired — las credenciales temporales caducaron.
Falta la región en la configuración

Referencias

Verificado por última vez el 2026-07-13 contra la documentación oficial de AWS enlazada arriba.

Reproducido el 2026-07-26 contra el servicio DynamoDB en vivo en us-east-1 — la salida de arriba es literal.