Guides de référence

Bonnes pratiques de sécurité

Comment intégrer Puwapi sans exposer vos données ni vos secrets.

Jetons et clés¶

JWT : de courte durée, à garder en mémoire côté client, jamais dans un cookie persistant ni un stockage durable. Rafraîchissez-le à 401.
Clé API serveur : traitez-la comme un mot de passe. Elle donne accès à votre organisation pour un module.
Scope minimal : une clé read si vous ne faites que lire ; write seulement si nécessaire.
Rotation : révoquez et recréez une clé compromise (DELETE), et faites tourner vos clés régulièrement.

Ponts M2M : le X-Internal-Secret doit être identique des deux côtés et jamais exposé côté navigateur. Un secret vide côté récepteur ferme la route (fail-closed) — volontaire.
Webhooks : utilisez un secret fort et unique ; vérifiez toujours la signature avant de traiter (voir Webhooks).

Le masquage côté interface (barre latérale, boutons) n'est pas une sécurité : c'est l'API qui fait autorité avec ses 401/403. Ne posez jamais votre contrôle d'accès sur le client.
L'isolation par organisation est appliquée au niveau du service : vous ne pouvez pas atteindre les données d'un autre tenant, et un 404 peut signifier « existe mais pas pour vous ».

L'IA ne persiste pas les résultats des features sensibles (mail_*, chat_*) ni les variables d'entrée ; ne contournez pas ce principe en journalisant ces contenus vous-même.
Les PAT GitHub et secrets de webhook stockés dans Work ne sont jamais renvoyés par l'API. Ne les réexposez pas.

Tout passe par HTTPS.
Les surfaces publiques (formulaires, portails) contrôlent les origines autorisées : déclarez précisément vos domaines plutôt que d'ouvrir à tous.

#reference #security