Sécurité

@vinkius/connect est conçu pour réduire au minimum la surface de secrets qu'un intégrateur doit gérer. Cette page présente le modèle, les garanties et la politique de divulgation.

Un seul secret

Le SDK s'initialise avec un ID d'application public (vk_app_*) et une clé d'application secrète unique (vk_app_sk_*). Le secret n'est envoyé que comme en-tête Authorization: Bearer via HTTPS.

• Une identité à chaque requête. Chaque appel transporte votre ID d'application vk_app_* et est validé côté serveur au moyen de la clé : une clé ne peut agir que pour sa propre application. Une vk_app_sk_* divulguée est limitée à une seule application ; l'API rejette les accès inter-locataires avec un 404.
• Conservez-la côté serveur. Dans une variable d'environnement ou votre gestionnaire de secrets. Ne l'envoyez jamais à un navigateur, une application mobile ou tout client contrôlé par l'utilisateur.

Le token de runtime n'atteint jamais le SDK

L'exécution des outils est mandatée par l'API Vinkius. Le token interne du plan de données (vk_live_*) est créé, renouvelé et utilisé entièrement côté serveur. Il n'existe aucun secret de runtime que votre application doive stocker ou puisse fuiter. Chaque appel via l'endpoint de runtime est mesuré et révocable (kill switch).

Les identifiants sont en écriture seule

Les identifiants des utilisateurs finaux sont stockés via l'API et jamais renvoyés. Le SDK peut uniquement indiquer quelles clés sont configurées, jamais leurs valeurs, et le modèle ne reçoit jamais de secrets bruts :

const state = await github.credentials.status();
// state.configured: Record<string, boolean> — flags, not values

Zéro dépendance de runtime

Le cœur est livré sans dépendances de runtime tierces, ce qui maintient une surface de chaîne d'approvisionnement minimale.

Expuration par défaut

Les hooks d'observabilité reçoivent des en-têtes et des corps expurgés. Authorization, les tokens et les champs assimilés à des identifiants n'atteignent jamais un logger via le SDK. L'expuration correspond à une liste fixe de noms de champs exacts, insensibles à la casse (authorization, token, api_key, credentials, password, secret, client_secret, entre autres), jusqu'à une profondeur maximale de six. Consultez l'API Reference pour les listes complètes.

Sécurité du transport

Les base URLs http:// autres que localhost émettent un avertissement dans la console ; utilisez toujours https:// en production.

Signaler une vulnérabilité

Signalez les problèmes de sécurité de manière privée à security@vinkius.com. N'ouvrez pas d'issues publiques pour les vulnérabilités. Les signalements font l'objet d'un accusé de réception sous 3 jours ouvrés et reçoivent un calendrier de remédiation après le triage.

Versions prises en charge

Les versions antérieures à 1.0 reçoivent des correctifs de sécurité sur la dernière version mineure. Maintenez @vinkius/connect à jour :

npm install @vinkius/connect@latest

Étapes suivantes

• Keep the application key behind a server boundary
• Redacted hooks and the full option reference
• Multi-tenant isolation patterns