DynamoDB IncompleteSignatureException

TL;DR — La signature AWS Signature Version 4 de la requête était incomplète ou non conforme aux standards AWS, donc DynamoDB l'a rejetée avant de l'authentifier. Si tu utilises un SDK AWS, la signature est automatique — cela signifie presque toujours une requête construite à la main ou un proxy/passerelle qui a altéré l'en-tête Authorization après la signature. Laisse le SDK signer, et assure-toi que rien ne réécrit la requête en transit.

Ce que ça signifie

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

AWS signe chaque requête avec SigV4. Cette exception signifie que la signature était présente mais malformée ou dépourvue de composants requis — un mauvais en-tête Authorization, un en-tête signé manquant, ou une incohérence de requête canonique. C'est une HTTP 400, côté client, et non réessayable en l'état : la signature doit être corrigée.

Pourquoi ça arrive

Signature faite à la main — tu construis la signature SigV4 toi-même (pas via un SDK) et la requête canonique, la liste des en-têtes signés ou l'en-tête Authorization est incorrecte.
Un en-tête Authorization malformé — les déclencheurs documentés sont un en-tête vide, un paramètre Credential ou Signature manquant, un en-tête qui ne commence pas par le nom de l'algorithme (AWS4-HMAC-SHA256), ou une paire clé=valeur sans signe égal.
Un proxy ou une passerelle d'API a réécrit la requête — muter l'en-tête Authorization (ou d'autres parties signées) après que le SDK a signé fait diverger l'en-tête reçu par AWS de celui que tu as envoyé.
En-têtes édités manuellement — ajouter/supprimer des en-têtes après la signature, ou réordonner la chaîne de requête, casse la requête canonique.

Comment le corriger

Utilise un SDK AWS officiel et laisse-le signer la requête. Les SDK implémentent SigV4 correctement pour toi — la correction pour presque toutes les occurrences est d'arrêter de signer à la main.
Ne mute pas la requête après la signature — si un proxy/une passerelle se trouve devant, assure-toi qu'il n'ajoute, ne supprime ni ne réordonne d'en-têtes et ne change pas le corps/le chemin. Signe à la frontière qui envoie effectivement la requête.
Vérifie si l'en-tête Authorization a changé en transit — le diagnostic documenté d'AWS : calcule un hachage SHA-256 de l'en-tête que tu as envoyé, encode-le en Base64, et compare-le au hachage que certains messages IncompleteSignatureException incluent. S'ils diffèrent, quelque chose entre ton client et AWS a modifié l'en-tête.
Si tu dois signer manuellement, suis le processus de signature AWS SigV4 exactement — la requête canonique, la chaîne à signer, la dérivation de la clé de signature et l'en-tête Authorization (algorithme, Credential=, SignedHeaders=, Signature=) doivent tous concorder. Vérifie par rapport à une requête SDK réputée correcte.

Une clé secrète erronée ou tronquée est un échec différent : elle produit une signature complète qui ne correspond pas, se manifestant par « signature we calculated does not match » plutôt que par cette erreur. De même, une horloge machine décalée se manifeste par Signature expired, pas par une signature incomplète.

DynoTable + Local

DynoTable emprunte le chemin de signature du SDK AWS — aucun SigV4 fait main — donc cette classe d'erreur n'apparaît pas en usage normal. Si ton app la rencontre alors que DynoTable fonctionne, compare les profils : Settings → Profiles → Test Connection avec les mêmes clés que celles que ton app charge.

Pour Local, des identifiants factices sur un profil pointant l'endpoint http://localhost:8000 contournent entièrement la signature. Vois Se connecter à AWS et Installation. Une fois les identifiants résolus, lance une requête de vérification dans le Query Builder.

Sources

Error handling with DynamoDB — IncompleteSignatureException (vérifié le 2026-07-13)
Troubleshoot Signature Version 4 signing (vérifié le 2026-07-13)

FAQ

Qu'est-ce qui cause une IncompleteSignatureException ? La signature AWS SigV4 de la requête était malformée ou dépourvue de parties requises — un en-tête Authorization vide ou malformé, un paramètre Credential ou Signature manquant, ou une paire clé=valeur sans signe égal. Avec un SDK AWS la signature est automatique, donc cela signifie généralement une signature construite à la main ou un proxy qui a altéré la requête après la signature.

En quoi est-ce différent d'UnrecognizedClientException ? IncompleteSignatureException signifie que la signature elle-même était malformée. UnrecognizedClientException (« security token is invalid ») signifie que la signature était bien formée mais que les identifiants derrière elle n'ont pas été acceptés.

Reproduire l'erreur

Envoie un en-tête Authorization présent, mais impossible à analyser comme du 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='{}',
)

Sortie réelle :

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

La chaîne Base64 finale est un hash de ton propre en-tête : elle change à chaque requête, ne filtre donc pas dessus. Ce que le message te dit est structurel : AWS a su lire l'algorithme, mais pas les paires Credential=/SignedHeaders=/Signature= qui suivent. Le problème est donc dans la façon dont l'en-tête a été assemblé, et c'est pourquoi cette erreur vient presque toujours d'une signature faite à la main plutôt que d'un SDK.

Erreurs liées

The request signature we calculated does not match — une signature complète mais erronée (mauvaise clé secrète ou canonisation).
The security token included in the request is invalid — signature bien formée, mauvais identifiants.
The security token included in the request is expired — identifiants temporaires expirés.
Missing region in config

Références

Dernière vérification le 2026-07-13 par rapport à la documentation officielle AWS liée ci-dessus.

Reproduit le 2026-07-26 sur le service DynamoDB réel dans us-east-1 — la sortie ci-dessus est reproduite telle quelle.