LeakGuard 0.4.0

LeakGuard

Prevent sensitive data from leaking into your .NET logs.

LeakGuard is a developer-first Roslyn analyzer that detects when values marked as PII, secrets, or sensitive data are passed directly to common logging APIs. Diagnostics appear at compile time in your IDE and in CI/CD pipelines — before sensitive data ever reaches production logs.

v0.4 adds object logging protection (LG004) so entire objects whose types contain LeakGuard-classified members are flagged when passed to ILogger.

v0.3 adds intra-procedural data-flow detection so sensitive values tracked through local variables, common string operations, and control-flow joins are flagged before they reach logging sinks.

v0.2 adds runtime redaction helpers and IDE quick fixes so you can resolve warnings safely without hand-editing every call site.

The problem

public sealed class Customer
{
    [Pii(PiiType.Email)]
    public string Email { get; init; } = "";
}

logger.LogInformation(
    "Created customer {Email}",
    customer.Email);

LG001: PII value Customer.Email may be exposed in logging.

Without LeakGuard, this compiles cleanly. With LeakGuard, you get an immediate, actionable warning pointing at the sensitive expression.

Quick fix (Visual Studio / Rider)

Place the caret on the warning and choose the light bulb quick action:

Redact email

logger.LogInformation(
    "Created customer {Email}",
    customer.Email.RedactEmail());

At runtime:

Created customer lu***@example.com

Diagnostics and quick fixes work in Visual Studio, JetBrains Rider, dotnet build, and CI.

Why LeakGuard?

• Explicit by design — Sensitivity is declared with attributes, not guessed from property names. Low false positives.
• Compile-time safety — Catches leaks before they ship.
• Actionable fixes — Redact email, phone, secrets, and generic sensitive values with one click.
• Runtime redaction — Best-effort masking when you must include a placeholder in structured logs.
• Incremental adoption — Mark sensitive members as you go; no logging framework changes required.
• Small and fast — A focused Roslyn analyzer; analysis stays lightweight.
• Ecosystem-friendly — Complements Microsoft.Extensions.Logging; not a replacement for it.

Installation

dotnet add package LeakGuard

One package includes attributes, runtime redaction helpers, Roslyn analyzers (LG001–LG004), and IDE code fixes.

Quick start

using LeakGuard;
using Microsoft.Extensions.Logging;

public sealed class Customer
{
    [Pii(PiiType.Email)]
    public string Email { get; init; } = "";
}

public class CustomerService(ILogger<CustomerService> logger)
{
    public void Create(Customer customer)
    {
        // Safe
        logger.LogInformation("Customer created {CustomerId}", customer.Id);

        // Warning LG001: PII value 'customer.Email' may be exposed in logging.
        logger.LogInformation("Created customer {Email}", customer.Email);
    }
}

Apply Redact email, rebuild, and the warning disappears.

Data-flow detection

LeakGuard tracks sensitive values through local assignments and common value-preserving operations within a single method.

[Pii(PiiType.Email)]
public string Email { get; init; } = "";

var email = customer.Email;
var normalized = email.Trim().ToLowerInvariant();

logger.LogInformation(
    "Customer {Email}",
    normalized);

LG001: PII value originating from Customer.Email may be exposed in logging.

Supported propagation includes:

• Local variables and reassignment (email = customer.Email, then copy = email)
• String operations such as Trim, ToLowerInvariant, Replace, and Substring
• String interpolation and concatenation
• Conditional expressions and null-coalescing (condition ? customer.Email : safe, customer.Email ?? fallback)
• Sensitive parameters marked with [Pii], [Secret], or [SensitiveData]
• Basic control-flow joins (if one branch assigns sensitive data, the merged value is treated as potentially sensitive)
• Sanitized values via LeakGuard's own Redact* extension methods break taint

Classification merge precedence when branches differ: Secret > Pii > SensitiveData.

Data-flow limitations (v0.3)

Current analysis is intra-procedural only. LeakGuard does not yet track sensitive data through:

• Arbitrary method calls (unless they are known taint-preserving string operations)
• Cross-method or cross-file data flow
• Repository/service boundaries, DTO mapping, serialization, or collection contents
• Reflection or external libraries
• Captured locals in complex closures, async continuations, or loops with back-edges (best-effort only)

var email = Normalize(customer.Email); // custom helper
logger.LogInformation("{Email}", email); // not tracked unless Normalize is recognized

Direct logging of marked members continues to work alongside data-flow detection.

Object logging protection

Developers often log entire objects without realizing the type contains sensitive members — or sensitive properties may be added later:

public sealed class Customer
{
    public Guid Id { get; init; }

    [Pii(PiiType.Email)]
    public string Email { get; init; } = "";

    [Pii(PiiType.Phone)]
    public string Phone { get; init; } = "";
}

logger.LogInformation(
    "Customer {@Customer}",
    customer);

LG004: Object 'Customer' contains sensitive data and may be exposed in logging.

This is separate from value-level diagnostics:

LG004 inspects the compile-time type of each logging argument for instance properties and fields marked with [Pii], [Secret], or [SensitiveData], including members inherited from base types. Records and local aliases (var value = customer) are supported.

Object logging limitations (v0.4)

• Direct and inherited members only — no recursive object-graph traversal (e.g. Order.Customer.Email through nested objects)
• No collection element inspection (List<Customer> is not analyzed)
• Compile-time type only — no speculative diagnostics for object or broad interface types without classified members
• Does not replace LG001–LG003 for individual sensitive values

Runtime redaction

The LeakGuard package provides small, dependency-free extension methods:

Nullable strings are handled naturally — null stays null; empty strings stay empty.

Email masking

Algorithm (deterministic, never throws):

• Keep the domain after @
• Keep up to two characters of the local part, then mask the rest with ***
• Fall back to generic *** when no @ is found

Phone masking

• Extract digits, keep a short prefix (up to 3 digits) and suffix (3 digits)
• Mask middle digits in place, preserving separators where present
• Not a full international phone parser — intentionally simple and predictable

Secret handling

RedactSecret() always returns ***. No prefix or suffix of the original value is preserved.

Prefer not logging secrets at all. Redaction is a last resort when a log line must retain a placeholder.

Code fixes

The package includes a Roslyn CodeFixProvider for:

Fix All is supported via BatchFixer for multiple occurrences of the same fix.

When using LeakGuard; is missing, the fix adds it automatically (including file-scoped namespaces).

Already-redacted values do not trigger diagnostics:

logger.LogInformation("{Email}", customer.Email.RedactEmail()); // OK

Redaction calls are recognized by semantic symbol matching on LeakGuard's own extension methods — unrelated user methods named Redact() are not trusted automatically.

PII vs SensitiveData vs Secret

Attributes can be applied to properties, fields, parameters, and return values.

PiiType values

Unknown, Name, Email, Phone, Address, PersonalIdentifier, Financial, Location

Specialized redactors for Name, Address, and other types may be added later. They currently use generic Redact().

Supported logging APIs

LeakGuard analyzes direct arguments passed to Microsoft.Extensions.Logging.ILogger extension methods:

• LogTrace, LogDebug, LogInformation, LogWarning, LogError, LogCritical

Both standard and Exception-first overloads are supported. Methods are identified semantically via Roslyn symbols.

Diagnostics

Diagnostics highlight the sensitive expression (e.g. customer.Email) or the logged object (e.g. customer), not the entire logging call.

Analyzer behavior

• Attribute-based only — Property names like Email or Password are not classified automatically.
• Direct, data-flow, and object logging — Individual sensitive values, tracked locals, and whole objects whose types contain classified members are flagged.
• Redaction-aware — LeakGuard's own Redact* extension methods break taint and are treated as safe.
• Generated code excluded — Source generators and generated files are not analyzed.
• Concurrent and scoped — Methods containing logging sinks are analyzed with CFG-based intra-procedural taint tracking.

This is flagged in v0.3:

var email = customer.Email;
logger.LogInformation("{Email}", email); // LG001

Reassignment is handled conservatively:

var email = customer.Email;
email = "safe";
logger.LogInformation("{Email}", email); // OK when overwrite is proven

Security considerations

LeakGuard is a developer safety tool. It is not:

• a complete GDPR compliance solution
• a DLP system
• a guarantee that sensitive data can never leak
• a substitute for correct logging policies
• a substitute for access controls

Runtime redaction algorithms produce best-effort safe representations for logs. They reduce accidental exposure but do not remove the underlying risk of logging sensitive data.

Secrets should ideally not be logged at all. Use redaction only when a placeholder is unavoidable, and prefer removing the secret from the log message entirely.

Performance

LeakGuard follows Roslyn analyzer best practices:

• Concurrent execution enabled
• Generated code excluded from analysis
• Methods containing logging sinks are analyzed with CFG-based data-flow tracking; others are skipped early
• No compilation-wide scans per syntax tree

The analyzer is designed to be invisible during normal IDE usage. Code fixes run only when you invoke them.

Roadmap

v0.4 (current)

• Object logging protection (LG004) for types containing LeakGuard-classified members
• Compilation-scoped type inspection cache for performance

v0.3

• Intra-procedural data-flow / taint tracking for locals, string ops, and control-flow joins
• Propagated diagnostic messages that reference the original sensitive source

v0.2

• Runtime redaction API (Redact, RedactEmail, RedactPhone, RedactSecret)
• IDE code fixes for LG001/LG002/LG003
• Redaction-aware analyzer (no repeated diagnostics)

v0.4

• Serilog support
• OpenTelemetry support

v1.0

• Stable analyzer API
• Configurable policies
• Custom sensitive attributes

Contributing

Contributions are welcome! Please open an issue to discuss significant changes before submitting a pull request.

1. Fork the repository
2. Create a feature branch
3. Add tests for analyzer and code-fix behavior
4. Ensure dotnet build and dotnet test pass
5. Open a pull request

License

MIT — see LICENSE.