Ce que je fais pour sécuriser une application .NET

La sécurité applicative, ce n'est pas seulement ajouter de l'authentication. Ça implique aussi de protéger le code, l'infrastructure, les données, les dependencies, et le processus de développement.

Utilisez le version control correctement

Git aide à suivre les changements, relire le code, et se remettre des erreurs.

Cependant, les fichiers sensibles ne devraient jamais être committés. J'utilise .gitignore pour exclure la configuration locale, les secrets, et les fichiers générés.

appsettings.Development.json
.env
*.user

Les repositories devraient aussi utiliser des pull requests et des code reviews avant que des changements importants soient mergés.

Ne jamais hardcoder les secrets

Les mots de passe, connection strings, API keys, et clés de signature JWT ne devraient pas être stockés directement dans le code source.

var connectionString =
    builder.Configuration.GetConnectionString("DefaultConnection");

Pendant le développement, j'utilise .NET User Secrets. Dans Azure, les secrets peuvent être stockés dans Azure Key Vault ou fournis via une configuration d'environnement sécurisée.

Protégez les endpoints de l'API

Les endpoints devraient être protégés avec de l'authentication et de l'authorization.

[Authorize]
[HttpGet("profile")]
public IActionResult GetProfile()
{
    return Ok();
}

Pour les opérations restreintes, j'utilise des roles ou des authorization policies :

[Authorize(Roles = "Admin")]

Les endpoints publics devraient être intentionnels. Les opérations sensibles ne devraient jamais dépendre seulement du frontend qui cache un bouton.

Configurez le JWT avec soin

Le JWT peut servir à authentifier des requests, mais les tokens doivent être validés correctement.

L'API devrait valider l'issuer, l'audience, la signature, et le temps d'expiration.

Les tokens devraient avoir une durée de vie raisonnable, et les clés de signature doivent être protégées. Les payloads JWT sont encodés, pas chiffrés, donc les mots de passe ou informations sensibles ne devraient jamais être placés dedans.

Suivez RBAC et le least privilege

L'AZ-900 m'a fait découvrir le Role-Based Access Control d'Azure. RBAC définit qui peut accéder à une resource et quelles actions il peut effectuer.

Le même principe s'applique à l'intérieur d'une application. Les utilisateurs, les services, et les comptes database ne devraient recevoir que les permissions dont ils ont besoin. Un compte database d'une application ne devrait pas avoir automatiquement un accès administrateur à tout le database server.

Utilisez HTTPS

HTTPS protège la communication entre les clients et l'API.

app.UseHttpsRedirection();

Les applications de production devraient utiliser des certificats TLS valides et éviter d'exposer des endpoints sensibles via du HTTP non chiffré.

Surveillez l'application

Les logs aident à identifier les erreurs, les activités suspectes, et les problèmes de performance. Des outils comme Grafana peuvent afficher des dashboards à partir de métriques collectées sur l'application et l'infrastructure.

Les signaux utiles incluent les tentatives de connexion échouées, les taux d'erreur élevés, un volume de requests inhabituel, des endpoints lents, et l'usage du CPU ou de la mémoire. Les logs ne devraient jamais contenir de mots de passe, d'access tokens, ou de données sensibles complètes.

Utilisez des dependencies fiables et à jour

Chaque dependency ajoute du code que je n'ai pas écrit mais dont mon application dépend quand même. Avant d'installer un package, je vérifie s'il est activement maintenu, s'il vient d'une source fiable, s'il a des vulnérabilités connues, et si l'application en a vraiment besoin.

Les packages devraient être mis à jour avec soin, testés, et relus plutôt qu'installés automatiquement sans en comprendre l'impact.

Relisez le code généré par un LLM

Les LLM peuvent aider à générer du code, de la configuration, et des fichiers d'infrastructure, mais leur output ne devrait jamais être accepté aveuglément. Je relis toujours chaque commande avant de l'exécuter, chaque package en cours d'installation, les changements d'authentication et d'authorization, les migrations de database, les secrets et la configuration, les fichiers Docker et de deployment, et tout code qui supprime ou modifie des données.

Le développeur reste responsable du code final.

Checklist finale

Utilisez le version control et les code reviews.
Ne hardcodez jamais les secrets.
Protégez les endpoints sensibles.
Validez correctement les tokens JWT.
Appliquez RBAC et le least privilege.
Utilisez HTTPS.
Surveillez les logs et les métriques.
Utilisez des dependencies fiables.
Relisez tout le code généré par un LLM.

La sécurité n'est pas une feature ajoutée à la fin. Elle devrait faire partie de chaque étape du développement.