Une interface web peut être lue, modifiée et rejouée par n'importe qui. Elle ne peut donc pas être responsable de ce qui est critique ou confidentiel. Voici la règle que nous nous donnons.
La règle
Tout ce qui est logique, exécution, paiement, e-mail, accès à la base de données ou lancement d'un agent s'exécute sur notre serveur. L'interface affiche ce que le serveur lui donne, par une API.
Concrètement :
- Connexion. Elle est gérée par le serveur. La session vit dans un cookie que le navigateur ne peut pas lire par script, et les requêtes qui modifient quelque chose sont protégées contre les envois forgés depuis un autre site.
- Droits. Le serveur décide qui peut inviter, retirer ou changer le rôle d'un membre, et il envoie à l'écran, avec chaque ligne, les actions permises et la raison d'un refus. Cacher un bouton n'est pas une protection : l'écran n'est qu'une commodité.
- Paiements. Stripe est appelé uniquement depuis le serveur. Un crédit n'est jamais accordé sans un événement signé par Stripe.
- E-mails. Ils partent de notre propre serveur de courrier, pas d'un service tiers branché au navigateur.
- Base de données. Seul le serveur y accède. L'interface n'a ni identifiant ni adresse de base.
Ce que cela coûte
Cette règle impose d'écrire plus de code côté serveur, et un chemin de plus à protéger : une partie de l'API devient joignable depuis Internet. Nous la protégeons par une limitation de débit, des contrôles à chaque requête et la fermeture de tout ce qui n'a pas à être public (supervision, documentation interne, points d'accès réservés aux agents).
Où en est la migration
La connexion est aujourd'hui encore gérée par l'interface, et sa migration vers le serveur est planifiée, pas terminée. Le modèle de données des comptes, des organisations et des invitations est écrit et testé côté serveur ; la connexion, les équipes et la facturation par siège suivent. Chaque étape sera publiée ici lorsqu'elle sera en ligne.
