Sécurité
Aucun développeur n'a besoin de se souvenir de filtrer une requête par organisation. Une portée globale s'en charge automatiquement, sur chaque modèle qui en a besoin, si bien qu'un identifiant obsolète ou deviné pour les données de quelqu'un d'autre ne résout rien, jamais une fuite.
Chacune ferme une façon différente dont une plateforme multi-tenant finit habituellement par fuir, discrètement, jusqu'à ce que quelqu'un se mette à chercher.
Une portée globale filtre chaque requête par organisation dès qu'un modèle démarre, sans rien qu'un développeur doive se rappeler et aucune requête isolée qui puisse l'oublier, y compris celles derrière les liens de route.
L'accès admin est vérifié à chaque requête, pas seulement à la connexion, si bien que suspendre une organisation verrouille son équipe dès le clic suivant. Ses produits cessent d'être accessibles publiquement au même instant.
Annuler un billet ou une commande exige sa permission spécifique revérifiée au moment exact de l'action, indépendamment de la permission qui a amené quelqu'un sur cet écran en premier lieu.
Le coût et la marge ne sont jamais écrits dans une réponse de boutique ou de scan aux portes. Ce n'est pas caché derrière un indicateur qui pourrait être mal configuré plus tard : le champ n'existe tout simplement jamais dans ce qui est renvoyé.
Comment ça tient
Cinq mécanismes, chacun fermant une façon différente dont l'isolation cède habituellement à l'usage réel.
Une portée globale ajoute le filtre d'organisation à chaque requête émise sur un modèle qui la porte, appliqué dès que le modèle démarre, sans filtre à retenir et sans qu'une seule requête puisse le contourner.
Les liens de route s'appuient sur cette même portée, si bien qu'un lien vers l'enregistrement d'une autre organisation résout en simple 404 avant même qu'un code de traitement ne s'exécute, jamais une erreur de permission qui confirmerait l'existence de l'enregistrement.
La portée seule protège les lectures et les suppressions, mais pas une écriture aveugle vers un identifiant étranger, donc un identifiant qui entre dans une table pivot ou une colonne de clé étrangère est d'abord revérifié via la requête à portée de sa propre cible.
Chaque action sensible relance un contrôle de permission en direct contre la base de données au moment où elle a réellement lieu, pas une seule fois au chargement de la page, si bien qu'une permission révoquée en cours de session cesse de fonctionner dès le clic suivant, pas à la prochaine connexion.
Supprimer un produit, une option ou une catégorie de billet avec de vraies ventes est refusé deux fois : la couche applicative explique pourquoi avant même de tenter l'opération, et la clé étrangère de la base de données elle-même est déclarée pour bloquer cette même suppression, si bien qu'un chemin qui contournerait le contrôle échouerait quand même.
Le détail, tel quel
La réponse qu'un scanner voit est une liste écrite à la main de ce dont le personnel aux portes a exactement besoin. Le coût, le prix net et la marge n'y ont jamais été ajoutés, donc il n'y a rien à exposer accidentellement plus tard.
{
"returned_to_gate_staff": {
"ticket_code": "AB12CD34EF",
"status": "redeemed",
"product_name": "City Food Tour",
"buyer_name": "Jane Buyer",
"position": 2,
"quantity": 3
},
"never_included": [
"cost_amount",
"net_amount",
"margin"
]
}Le détail que presque personne n'explique
Un audit a trouvé huit modèles accessibles en devinant un identifiant d'une autre organisation : six régissant les règles de prix et de disponibilité, deux régissant les affectations de taxes. Aucun ne portait son propre filtre d'organisation ; chacun héritait celui d'une relation parente qu'une recherche brute par un identifiant fourni par le client contournait entièrement. Chacun d'eux porte désormais son propre identifiant d'organisation, fermant cette catégorie exacte de faille pour de bon, et une suite de tests dédiée la maintient fermée en tentant précisément cette supposition, sur chacun des huit, à chaque exécution de la suite.
Non. Chaque modèle qui en a besoin porte une portée globale filtrant par organisation automatiquement, ce qui protège aussi les liens de route : un identifiant obsolète ou deviné pour l'enregistrement d'une autre organisation résout en 404, jamais une erreur de permission qui confirmerait l'existence de l'enregistrement.
Son équipe admin perd l'accès au panneau dès la requête suivante, pas seulement à la prochaine connexion, et ses produits cessent d'être accessibles via l'API publique au même instant. La suspension est appliquée, pas seulement enregistrée.
Oui. Chaque action sensible revérifie la permission en direct contre la base de données au moment où elle s'exécute, jamais un rôle mis en cache au premier chargement de la page. Le tout premier clic après une révocation est bloqué.
Non, à double titre. La couche applicative refuse la suppression avec une explication claire avant même de la tenter, et la clé étrangère de la base de données elle-même est déclarée pour restreindre cette même suppression, si bien que même un chemin qui contournerait le contrôle applicatif échouerait quand même.
Non. Ces réponses sont écrites à la main pour n'inclure que ce dont le destinataire a réellement besoin. Le champ n'est jamais écrit dans la réponse en premier lieu, pas caché derrière un indicateur qui pourrait être mal configuré.
Tiqory garde disponibilité, tarifs, paiements et accès parfaitement synchronisés à mesure que votre activité grandit. Dites-nous où vous allez ; nous vous montrons comment y arriver sans repartir de zéro.