15 articles tagués avec « Security »

STOA exécute 9 jobs de sécurité en parallèle sur chaque pull request — scanning de secrets, SAST pour trois langages, audits de dépendances, scanning de containers, conformité des licences, génération de SBOM et vérification des signatures de commits. Cet article détaille chaque job, explique ce qu'il détecte et vous montre comment adopter la même approche dans vos propres projets. C'est dans l'esprit de notre philosophie de gateway API open source : le scanning de sécurité doit être intégré dans le CI, pas rajouté après une compromission.

Faire fonctionner un gateway API en production exige bien plus que de déployer avec des paramètres par défaut. Un gateway mal sécurisé expose chaque service backend aux attaques, laisse fuiter des données sensibles et crée des cauchemars de conformité. Cette checklist de durcissement en 10 étapes couvre les contrôles critiques à mettre en place avant tout déploiement en production. Chaque étape comprend des exemples de configuration concrets et des commandes de vérification.

Les agents IA ont besoin d'un accès programmatique aux APIs, mais les patterns d'authentification traditionnels conçus pour les utilisateurs humains — cookies de navigateur, tokens de session, flows d'autorisation OAuth2 — ne fonctionnent pas. Les agents IA sont des services autonomes, pas des utilisateurs. Ils opèrent sans navigateur, sans interactions humaines dans la boucle, et à la vitesse des machines. Cet article présente cinq patterns d'authentification qui fonctionnent pour les agents IA, du plus simple (API keys) au plus sécurisé (liaison de certificat mTLS), avec des exemples d'implémentation pratiques pour chacun.

Il fait partie de la série Qu'est-ce qu'un MCP Gateway. Pour le contexte plus large sur pourquoi les agents IA ont besoin d'une infrastructure spécialisée, consultez Connecter les agents IA aux APIs enterprise.

10 étapes de sécurité pratiques qui prennent moins d'une journée et préviennent 95 % des incidents API. Pas de budget enterprise, pas d'outillage complexe — juste de la rigueur d'ingénierie. Couvre les secrets, le rate limiting, CORS, l'authentification, TLS, les logs et la gestion des dépendances.

Vous êtes freelance. Vous avez livré une API pour un client. Elle fonctionne. Les tests passent. La facture est envoyée.

Six mois plus tard, le client vous appelle : quelqu'un a extrait toute leur base de données utilisateurs via votre API. Pas de rate limiting. Pas de validation des entrées. Headers CORS par défaut. La clé API était dans le JavaScript frontend.

Cela arrive plus souvent qu'on ne l'admet. Et c'est presque toujours évitable avec une simple checklist. C'est une partie de notre philosophie de gestion d'API open source : la sécurité doit être accessible à tous, pas seulement aux entreprises.

Les clés API supprimées restent dans l'historique git pour toujours. Cet article vous montre comment détecter les secrets exposés avec gitleaks, les supprimer de l'historique, et prévenir les fuites futures avec des hooks pre-commit et une gestion correcte des secrets.

Vous avez supprimé la clé API codée en dur de votre code. Vous avez commité la correction. Vous avez poussé. Vous êtes en sécurité maintenant, n'est-ce pas ?

Non. La clé est toujours dans votre historique git. N'importe qui avec git log -p peut la trouver en quelques secondes.

Ce n'est pas un risque théorique. GitHub scanne plus de 100 millions de commits par jour et trouve des milliers de secrets valides — clés API, mots de passe de bases de données, credentials cloud. La plupart d'entre eux ont été "supprimés" par des développeurs qui pensaient que supprimer la ligne était suffisant.

C'est l'une des failles de sécurité les plus critiques dans le développement API moderne — et l'une des raisons pour lesquelles nous avons construit STOA en tant qu'API gateway open source avec la gestion des secrets comme fonctionnalité par défaut, pas comme add-on.