Explorer le développement AI-first, les garde-fous de code et l'architecture de la jetabilité.
L'autorité ambiante signifie que n'importe quel code dans votre processus Node.js peut toucher le système de fichiers, le réseau et l'environnement. Voici comment l'éliminer avec lockdown, les compartments et le passage explicite de capabilities.
Une seule dépendance transitive compromise peut exfiltrer votre , écrire sur votre système de fichiers et ouvrir des connexions sortantes. Elle n'a pas besoin…
La plupart de la confiance entre services vient de leur emplacement réseau, pas d'une preuve cryptographique. Voici comment les capabilities, le mTLS et SPIFFE permettent aux services de s'authentifier sans autorité ambiante, et pourquoi c'est plus difficile que ça ne devrait l'être.
Vos microservices partagent un VPC, donc ils se font confiance. Cette confiance est une autorité ambiante : la permission d'invoquer un service n'est accordée…
La bibliothèque standard de Rust accorde une autorité ambiante sur le système de fichiers à chaque dépendance. cap-std la remplace par des APIs basées sur les capabilities qui forcent le code à prouver qu'il a le droit d'accéder à un chemin avant de l'ouvrir.
N'importe quelle crate dans votre arbre de dépendances peut ouvrir , écrire dans votre répertoire , ou énumérer chaque fichier de votre projet. La bibliothèque…
Une attaque par député confus trompe un service privilégié pour qu'il utilise son autorité contre lui-même. Voici comment les attaquants exploitent la confiance implicite, et pourquoi la sécurité basée sur les capabilities est la solution.
Votre service dispose d'une clé API pour votre stockage cloud. Un utilisateur envoie une requête. Votre service écrit fidèlement un fichier. Le fichier…
La capability-based security remplace les vérifications de rôles dispersées par des tokens d'autorité inforgeables. Voici comment l'implémenter en TypeScript sans rendre votre code illisible.
Chaque bug de permission se ressemble avec le recul. Une fonction au fond du call stack suppose que l'appelant a déjà vérifié . Ce n'était pas le cas. Ou un…
La plupart du code s'exécute avec une autorité ambiante : chaque fonction peut toucher à tout. La sécurité basée sur les capacités renverse ce modèle en obligeant les fonctions à recevoir des permissions explicites et limitées.
Votre fonction a accès à la base de données, à la passerelle de paiement et au journal d'audit parce qu'elle se trouve par hasard dans le même processus. Si un…
Les exceptions lancées masquent les chemins d'échec à votre système de types. Voici pourquoi les retours d'erreur explicites rendent votre code plus honnête, et comment les adopter sans vous détester.
La signature de votre fonction dit qu'elle retourne un . C'est faux. Elle retourne un ou elle explose. Le système de types ne connaît simplement pas la seconde…
Un struct wrapper à un seul champ attrape les bugs de mélange d'unités et la confusion de types sans ajouter un seul octet d'overhead.
Passez un identifiant utilisateur à une fonction qui attend un identifiant de commande, et Rust ne se plaindra pas. Les deux sont des . Le compilateur voit des…
Les instructions switch TypeScript vous laissent silencieusement oublier des cas. Voici comment les remplacer par des patterns avec exhaustiveness checking qui font échouer le build au lieu de l'exécution.
Vous avez refactorisé un type de forme, ajouté une nouvelle variante, et TypeScript est resté vert. Votre CI a passé. Votre déploiement est parti. Puis un…
Ajouter un nouvel état à votre machine est facile. Se souvenir de mettre à jour chaque switch ne l'est pas. Voici comment faire en sorte que TypeScript refuse de compiler quand vous oubliez un cas.
Les state machines commencent propres. Trois valeurs, trois branches switch. Puis la logique de retry ajoute un quatrième état. L'échec partiel ajoute un…