Sécuriser son API de signature : les 10 règles

Ce qu'il faut retenir

• Une API de signature manipule des documents sensibles et des preuves.
• L'authentification et l'autorisation sont les premières lignes de défense.
• Les secrets ne doivent jamais être partagés ni exposés.
• Journalisation, limites de débit et audit complètent la sécurité.

Une API de signature électronique est une porte d'entrée vers des documents et des preuves. La sécuriser est essentiel. Voici les dix règles à appliquer.

1. Authentifier et autoriser

• Utiliser des clés d'API dédiées par intégration.
• Restreindre les permissions au minimum nécessaire.
• Révoquer immédiatement les clés compromises.
• Penser aux tokens courts quand l'intégration le permet.

Une clé puissante partagée entre services multiplie le risque.

2. Protéger les secrets

• Stocker les clés dans un coffre (secret manager).
• Ne jamais les versionner ni les loguer.
• Les injecter par variables d'environnement.
• Pivoter les clés régulièrement.

3. Chiffrer les transports

Utiliser exclusivement HTTPS/TLS :

• le trafic est chiffré en transit ;
• l'identité du serveur est vérifiée ;
• les certificats sont contrôlés.

Toute requête non chiffrée expose le document et les preuves.

4. Valider les entrées

• Valider types, tailles et formats des fichiers.
• Rejeter les pièces jointes inattendues.
• Limiter la taille des documents.
• Contrôler les champs et les métadonnées.

5. Maîtriser les droits par ressource

Chaque action doit être autorisée selon son périmètre.

6. Sécuriser les webhooks

• Signer chaque événement avec un secret.
• Vérifier la signature à la réception.
• Rejouer les événements en cas de doute.
• Ne jamais faire confiance à l'URL seule.

7. Limiter le débit

Le rate limiting protège contre :

• les abus et le spam ;
• les attaques de force brute ;
• la saturation de l'API.

Des quotas par clé et par action évitent la dégradation du service.

8. Journaliser et auditer

• Enregistrer chaque appel (qui, quoi, quand).
• Conserver les logs de sécurité.
• Protéger les journaux contre l'altération.
• Surveiller les anomalies.

9. Gérer les dépendances

• Maintenir à jour les bibliothèques.
• Suivre les vulnérabilités connues.
• Réduire les dépendances inutiles.
• Auditer les composants tiers.

10. Préparer l'incident

• Documenter les procédures de révocation.
• Prévoir la récupération des données.
• Tester les scénarios de compromission.
• Notifier selon les obligations (CNIL).

Erreurs fréquentes à éviter

• Clé en dur dans le code ou dans un dépôt.
• Permissions trop larges.
• Webhooks non vérifiés.
• Pas de journalisation.
• Bibliothèques obsolètes.

Checklist de sécurité

1. Clés dédiées et coffrées.
2. HTTPS exclusif.
3. Entrées validées.
4. Webhooks signés.
5. Rate limiting actif.
6. Logs et audit.
7. Plan d'incident prêt.

Pour aller plus loin

• API de signature — l'intégration.
• OAuth 2 et SSO — l'authentification.
• Réaction à incident — le plan de réponse.

Questions fréquentes

Faut-il une clé par intégration ?

Oui, pour limiter l'impact d'une compromission et tracer les usages.

Comment vérifier un webhook ?

En signant chaque événement avec un secret partagé et en vérifiant la signature à la réception.

Que faire en cas de fuite de clé ?

Révoquer immédiatement, vérifier les accès et les logs, puis délivrer une nouvelle clé.

Sources officielles

• OWASP API Security Top 10
• CNIL — bonnes pratiques de sécurité
• RFC 6749 — OAuth 2.0

Pour aller plus loin

Le plan de réponse à incident complète ces règles. Voir l'article sur la réaction à incident.

Ce contenu est une information technique générale et ne remplace pas un audit de sécurité adapté.