DEV Community: Klein Houzin

Implémenter une politique de logging pour les Equipes IT

Klein Houzin — Thu, 23 Oct 2025 06:10:15 +0000

Introduction

Dans l'ère numérique actuelle, à l'époque de l'IA, les logs sont bien plus que de simples traces techniques - ce sont les yeux et les oreilles de votre infrastructure IT. Une politique de logging bien définie n'est pas un luxe, mais une nécessité stratégique pour toute entreprise soucieuse de sa sécurité et de sa performance.

Pourquoi une Politique de Logging Est Essentielle

Les Enjeux Clés

Sécurité : Détection des intrusions et menaces
Conformité : Respect du RGPD et autres réglementations
Performance : Monitoring des systèmes et applications
Audit : Traçabilité complète des activités

💡 Le saviez-vous ? Sans politique de logging, vous naviguez à l'aveugle en cas d'incident.

Les 5 Piliers d'une Politique de Logging Robuste

1. Classification Intelligente des Logs

Niveau Usage Conservation

🔴 CRITIQUE Incidents majeurs 1 an
🟠 ERREUR Bugs fonctionnels 6 mois
🟡 AVERTISSEMENT Anomalies 3 mois
🔵 INFORMATION Activité normale 3 mois
⚪ DEBUG Développement 30 jours

2. Standardisation du Format

Adoptez un format structuré comme le JSON pour faciliter l'analyse :

{
  "timestamp": "2024-01-15T10:30:00Z",
  "level": "ERROR",
  "service": "app-métier",
  "user": "john.doe",
  "event": "authentification_failure",
  "message": "Échec connexion"
}

3. Sécurisation des Logs

Chiffrement des données au repos
Contrôle d'accès strict (principe du moindre privilège)
Intégrité garantie contre les modifications
Stockage sécurisé et dédié

4. Conservation Adaptée

Ne gardez pas tout, mais gardez l'essentiel !

Logs de sécurité : 1 an (conformité RGPD)
Logs applicatifs : 6 mois (support technique)
Logs de debug : 30 jours (développement)

Tout ceci ne peut être fait qu'avec de bons outils. Mais de grâce, séparez vos logs debug et informations des logs d'erreurs. Ils n'ont pas la même durée de vie.

5. Monitoring Actif

Tableaux de bord temps réel
Alertes automatiques sur comportements suspects
Analytics prédictifs
Rapports de conformité automatiques

Mise en Œuvre : Par où Commencer ?

Phase 1 : Inventaire (Semaines 1-2)

Cartographiez tous vos systèmes
Identifiez les données critiques
Priorisez les applications stratégiques

Phase 2 : Standardisation (Semaines 3-4)

Définissez vos formats de logs
Configurez les niveaux de journalisation
Implémentez les outils de collecte

Phase 3 : Sécurisation (Semaines 5-6)

Mettez en place le contrôle d'accès
Chiffrez les données sensibles
Automatisez les sauvegardes

Bonnes Pratiques à Adopter Absolument

À Faire

Journalisez les tentatives d'authentification (succès et échecs)
Tracez les accès aux données sensibles
Monitoriez les modifications de configuration
Conservez les logs de sécurité 1 an minimum

À Éviter

Ne journalisez pas les mots de passe en clair
Ne surchargez pas avec des informations inutiles
N'oubliez pas les aspects conformité légale
Ne négligez pas la performance des applications

Cas d'Usage : Sécurité et Conformité

Détection d'Intrusion

02:15 - Tentative de connexion échouée (compte admin)
02:16 - 50 tentatives depuis la même IP
02:17 - Alerte automatique à l'équipe sécurité
02:18 - Blocage de l'IP suspecte

Audit RGPD

Accès aux données personnelles tracés
Consentements utilisateurs journalisés
Droit à l'oubli implémenté
Preuves de conformité disponibles
Mesurer l'Efficacité de Votre Politique

** KPIs à Suivre **

Temps de détection des incidents

Nombre d'alertes pertinentes

Couverture des systèmes journalisés

Temps de rétention effectif

Conformité aux réglementations

Les Tendances Futures du Logging

L'Avenir est ...

Intelligent : IA pour l'analyse des logs (nous y reviendrons)
Cloud Native : Solutions serverless
Unifié : Centralisation multi-sources
Temps Réel : Streaming et analytics instantanés (de grace n'allez pas au temps réel si personne n'est là pour monitorer)

Conclusion : Votre Plan d'Action

Dès demain, vous pouvez :

Auditer votre situation actuelle (très importante. Accepter la réalité ne crève pas les yeux)
Définir les priorités de journalisation
Former vos équipes aux bonnes pratiques (former surtout les équipes systèmes)
Implémenter les outils de base
Passer votre politique de logging dans votre prompt d'IA

Dans 3 mois, vous pourrez :

✅ Détecter les incidents plus rapidement
✅ Répondre aux audits en toute sérénité
✅ Améliorer la performance de vos applications
✅ Dormir sur vos deux oreilles !

🧠 Two “AllowedHosts” Every Developer Should Know

Klein Houzin — Wed, 22 Oct 2025 04:04:31 +0000

Whether you’re in .NET, Node.js, Java, or Python — you need to care about what hosts your app trusts.
This is one of those small details that can quietly make or break your app’s security posture.

And it’s straight out of the OWASP Top 10:
→ A10:2021 – Server-Side Request Forgery (SSRF) and
→ A01:2021 – Broken Access Control.

Let’s check both sides of “allowed hosts”

1️⃣ The Built-in One: Protecting Inbound Traffic

In ASP.NET Core, you’ll often see this in appsettings.json:

{
  "AllowedHosts": "example.com"
}

That’s not for redirects, API calls, or URLs inside your app.
It’s for incoming HTTP requests — it tells your app which Host headers are allowed.
If someone tries to access your server as https://evilproxy.com, the request is dropped.

Think of it as your front door lock 🏠 —
It stops fake domains from pretending to be you.

💡 Other frameworks have similar controls:

Express.js → use helmet() or host-validation middleware

Django → ALLOWED_HOSTS in settings.py

Spring Boot → server.forward-headers-strategy with a proxy-aware filter

2️⃣ The Custom One: Protecting Outbound URLs (OWASP SSRF)

Now comes the untold part:
Even if your app’s front door is locked, what about the URLs inside it?

When users can submit or trigger URLs (for example, a redirect after login, a webhook, or an image fetch), attackers can trick your backend into calling something internal like http://localhost:8080/admin.

That’s Server-Side Request Forgery (SSRF) — and it’s on OWASP’s radar for a reason.
The fix? A custom whitelist middleware that validates every URL before use.

🧱 Code Example: .NET Middleware to Block Untrusted URLs

Here’s a simple example in C# — easy to adapt to any stack:



using Microsoft.AspNetCore.Http;
using Microsoft.Extensions.Options;
using System;
using System.Linq;
using System.Threading.Tasks;

public class UrlWhitelistMiddleware
{
    private readonly RequestDelegate _next;
    private readonly string[] _allowedHosts;

    public UrlWhitelistMiddleware(RequestDelegate next, IOptions<SecuritySettings> settings)
    {
        _next = next;
        _allowedHosts = settings.Value.AllowedHosts;
    }

    public async Task InvokeAsync(HttpContext context)
    {
        var returnUrl = context.Request.Query["returnUrl"].ToString();

        if (!string.IsNullOrEmpty(returnUrl) && !IsAllowed(returnUrl))
        {
            context.Response.StatusCode = 400;
            await context.Response.WriteAsync("Blocked: Untrusted redirect target.");
            return;
        }

        await _next(context);
    }

    private bool IsAllowed(string url)
    {
        if (!Uri.TryCreate(url, UriKind.Absolute, out var uri))
            return false;

        if (uri.Scheme != Uri.UriSchemeHttps && uri.Scheme != Uri.UriSchemeHttp)
            return false;

        return _allowedHosts.Any(host =>
            uri.Host.Equals(host, StringComparison.OrdinalIgnoreCase) ||
            uri.Host.EndsWith("." + host, StringComparison.OrdinalIgnoreCase));
    }
}

public class SecuritySettings
{
    public string[] AllowedHosts { get; set; } = Array.Empty<string>();
}

Add your whitelist in appsettings.json:

{
  "Security": {
    "AllowedHosts": [ "example.com", "trustedpartner.org" ]
  }
}

And register it in your app:

app.UseMiddleware<UrlWhitelistMiddleware>();

✅ TL;DR — What Devs Should Remember

Purpose Type Example OWASP Relevance

Inbound host validation Built-in AllowedHosts Prevents Host Header Injection A05:2021
Security Misconfiguration
Outbound / redirect URL validation Custom middleware whitelist Prevents SSRF, open redirects A10:2021 – SSRF

🔐 Final Word

Whether you write in .NET, Node, or Go, make your app paranoid about URLs like you are when clicking on a link received in an email.
A trusted host list is one of the simplest, cheapest, and most effective shields against SSRF and open redirect attacks.

🧩 Lock the door. Guard the window.
OWASP and Reality has been warning us for years — time to listen, especially devs and software architects.

🚀 Building Truly Resilient SQL Server Applications in .NET

Klein Houzin — Thu, 16 Oct 2025 07:16:38 +0000

Introduction

Modern enterprise systems rarely fail because of code — they fail because of transient infrastructure conditions.

Whether you’re running on Azure SQL, SQL Server in Kubernetes, or on-prem clusters, you will inevitably face temporary failures: network drops, throttling, deadlocks, DNS hiccups, or resource contention.
These are not permanent faults — they are part of the system’s natural breathing pattern.

The key is not to panic, but to build resilience.

In .NET and Entity Framework Core, this resilience is achieved through Execution Strategies and configurable retry logic.
But here’s the catch: the default retry logic doesn’t always cover every transient condition you’ll encounter in production.

That’s where extending the transient error numbers becomes crucial.

The Hidden Edge: `errorNumbersToAdd`

When you configure SQL resiliency in .NET, one of the most powerful yet overlooked parameters is:

errorNumbersToAdd

This parameter allows you to extend the list of SQL error codes that are treated as transient — meaning, errors that are safe to retry automatically.

Out of the box, EF Core’s SqlAzureExecutionStrategy already knows how to handle the common suspects (e.g., 40613, 40197, 40501, etc.).
But in the field, architects often discover additional transient patterns specific to their workloads — deadlocks, resource throttling, or connection resets — that don’t get retried by default.

If your retry logic doesn’t recognize them, it fails unnecessarily — producing false negatives, failed transactions, and unneeded alerts.

The Architecture of Resilience

A well-designed retry mechanism must be:

Deterministic — only retry on known transient conditions.
Bounded — never retry endlessly.
Idempotent — safe to re-execute operations.
Transparent — log every retry attempt for observability.

Extending errorNumbersToAdd strengthens that architecture by covering real-world transient faults that your database layer may throw.

The Battle-Tested Transient Error Codes

Here’s a curated list — drawn from real enterprise production systems — of SQL Server and Azure SQL error codes that should absolutely be treated as transient.

These are the codes you’ll want in your retry configuration:

new[]
{
    // Network & Connection Failures
    20,     // Fatal error in current connection
    53,     // Cannot open a connection to SQL Server
    64,     // Network name deleted
    10053,  // Network connection aborted
    10054,  // Connection reset by peer
    10060,  // Network timeout
    11001,  // DNS lookup failure
    17197,  // SSL / encryption issue under load

    // Resource or Throttling
    40197,  // Azure SQL internal transient error
    40501,  // Throttling (Too many requests)
    40549,  // Session terminated due to transaction timeout
    40613,  // Database unavailable
    40615,  // Database failover in progress
    10928,  // Resource limit reached
    10929,  // Resource throttling
    10936,  // Resource governor limit

    // Concurrency
    1205,   // Deadlock victim

    // Login / Session Availability
    233,    // Connection initialization failed
    18401,  // Login failed: database unavailable
    18456,  // Login failed for user (transient in Azure)
}

These numbers cover the real surface of transient volatility — from network oscillations to throttling and failover events.

How to Apply Them in EF Core

In your Program.cs or Startup.cs, configure your DbContext like this:

builder.Services.AddDbContext<AppDbContext>(options =>
    options.UseSqlServer(
        connectionString,
        sqlOptions =>
        {
            sqlOptions.ExecutionStrategy(deps =>
                new SqlAzureExecutionStrategy(
                    dependencies: deps,
                    maxRetryCount: 7,
                    maxRetryDelay: TimeSpan.FromSeconds(10),
                    errorNumbersToAdd: new[]
                    {
                        20, 53, 64, 10053, 10054, 10060, 11001, 17197,
                        40197, 40501, 40549, 40613, 40615,
                        10928, 10929, 10936,
                        1205, 233, 18401, 18456
                    }
                )
            );
        }));

Now, when your application encounters these errors, EF Core automatically retries the operation before surfacing an exception.
That’s production-grade resilience with minimal code.

Advanced Option — Unified Retry Policy

Architects managing both EF and raw ADO.NET calls can centralize retry configuration:

public static class SqlRetryPolicy
{
    public static readonly int[] AdditionalTransientErrors =
    {
        20, 53, 64, 10053, 10054, 10060, 11001, 17197,
        40197, 40501, 40549, 40613, 40615,
        10928, 10929, 10936,
        1205, 233, 18401, 18456
    };

    public static SqlRetryLogicBaseProvider CreateProvider()
    {
        var options = new SqlRetryLogicOption
        {
            NumberOfTries = 7,
            DeltaTime = TimeSpan.FromSeconds(2),
            MaxTimeInterval = TimeSpan.FromSeconds(10),
            AdditionalErrorNumbers = new HashSet<int>(AdditionalTransientErrors)
        };

        return SqlConfigurableRetryFactory.CreateFixedRetryProvider(options);
    }
}

Then apply it to both ADO.NET connections and EF contexts — a single source of truth for retry logic across your stack.

Key Lessons for Architects

Know your environment. Azure SQL behaves differently under throttling than on-prem SQL Server. Observe which errors are transient in your setup.
Log intelligently. Retrying hides transient faults, but you still need visibility. Instrument retry events through structured logging.
Avoid over-retrying. Retrying too aggressively under heavy load can worsen the problem. Respect backoff intervals.
Protect idempotency. Only retry operations that can safely be re-executed. Avoid side-effect–heavy business logic in the same transaction scope.

Conclusion

Resilience isn’t just about writing “retry code.” It’s about understanding the system’s failure modes and engineering your software to breathe with them.

By extending errorNumbersToAdd with the right SQL error codes, you move from reactive error handling to architectural fault tolerance.
Your systems stop failing for the wrong reasons — and start recovering automatically from the right ones.

That’s what separates good systems from great architectures.

Channels in .NET 8

Klein Houzin — Mon, 06 Oct 2025 09:02:50 +0000

In .NET Core, System.Threading.Channels are preferred over classic queues like ConcurrentQueue<T> for high-performance producer–consumer scenarios. Here’s why Channel is better in all your implementations instead of a traditional Queue or ConcurrentQueue.

1. Channels are purpose-built for asynchronous producer–consumer workflows

A Channel<T> provides both:

a writer for producers (e.g., code that enqueues HTTP requests), and
a reader for consumers (background workers processing those requests).

Unlike a regular queue, a Channel natively supports:

asynchronous writes and reads (WriteAsync, ReadAsync),
backpressure (bounded capacity), and
completion signaling (knowing when no more items will arrive).

This matches exactly what a background HTTP queue needs.

2. Built-in backpressure (bounded capacity)

When using Channel.CreateBounded<T>(), you can specify a maximum capacity and a policy for what happens when it’s full:

Channel.CreateBounded<RequestJob>(new BoundedChannelOptions(5000)
{
    FullMode = BoundedChannelFullMode.Wait
});

This prevents unbounded memory growth when producers enqueue faster than consumers can process. A normal queue would keep growing until memory runs out.

3. Non-blocking async operations

Channel<T> integrates with async/await. Writers can await channel.Writer.WriteAsync() and yield control instead of blocking threads. Readers can await channel.Reader.ReadAsync() to efficiently wait for new items. This is ideal for background services in ASP.NET Core, which should be non-blocking and cooperative.

4. Thread safety without locking

Channel<T> is fully thread-safe and internally optimized for multiple writers and readers. Unlike manual queue + lock approaches, Channels avoid lock contention and use lock-free algorithms where possible.

5. Graceful shutdown support

When the hosted service stops, the channel can be completed or cancelled, letting readers finish processing remaining jobs. This helps with controlled termination:

_channel.Writer.Complete();
await foreach (var item in _channel.Reader.ReadAllAsync()) { ... }

With a classic queue, you’d have to invent your own shutdown signaling.

6. Integration with async streams

Channels expose an IAsyncEnumerable<T> via ReadAllAsync(). This allows idiomatic streaming loops like:

await foreach (var job in channel.Reader.ReadAllAsync(ct))
{
    await Process(job);
}

This syntax is clean, safe, and natively supports cancellation.

7. Designed for high throughput

Channels are implemented in highly optimized C# and use efficient internal buffers. Benchmarks show Channels outperform many manual queue + semaphore implementations for async workloads.

Summary Table

Feature	Channel	ConcurrentQueue
Async writes/reads	✅	❌
Bounded capacity	✅	❌
Backpressure	✅	❌
Graceful shutdown	✅	⚠ (manual)
Lock-free concurrency	✅	✅
Integrated with async streams	✅	❌

In short

Using Channel<T> makes your class:

safer (no manual thread signaling),
more memory-efficient (bounded queues), and
naturally asynchronous (no blocking threads).

This aligns perfectly with .NET 8 background service patterns and Microsoft’s modern async design guidance.

Next time, we will talk about

DEV Community: Klein Houzin

Implémenter une politique de logging pour les Equipes IT

Introduction

Pourquoi une Politique de Logging Est Essentielle

Les Enjeux Clés

Les 5 Piliers d'une Politique de Logging Robuste

1. Classification Intelligente des Logs

2. Standardisation du Format

3. Sécurisation des Logs

4. Conservation Adaptée

5. Monitoring Actif

Mise en Œuvre : Par où Commencer ?

Phase 1 : Inventaire (Semaines 1-2)

Phase 2 : Standardisation (Semaines 3-4)

Phase 3 : Sécurisation (Semaines 5-6)

Bonnes Pratiques à Adopter Absolument

Cas d'Usage : Sécurité et Conformité

Les Tendances Futures du Logging

Conclusion : Votre Plan d'Action

🧠 Two “AllowedHosts” Every Developer Should Know

1️⃣ The Built-in One: Protecting Inbound Traffic

2️⃣ The Custom One: Protecting Outbound URLs (OWASP SSRF)

🚀 Building Truly Resilient SQL Server Applications in .NET

Introduction

The Hidden Edge: errorNumbersToAdd

The Architecture of Resilience

The Battle-Tested Transient Error Codes

How to Apply Them in EF Core

Advanced Option — Unified Retry Policy

Key Lessons for Architects

Conclusion

Channels in .NET 8

1. Channels are purpose-built for asynchronous producer–consumer workflows

2. Built-in backpressure (bounded capacity)

3. Non-blocking async operations

4. Thread safety without locking

5. Graceful shutdown support

6. Integration with async streams

7. Designed for high throughput

Summary Table

In short

The Hidden Edge: `errorNumbersToAdd`