C# and .NET Security

.NET has spent a decade removing its sharpest edges, which changes what a review is looking for. The deserialization finding that was critical in 2016 is now usually a .NET Framework project nobody migrated, and the injection finding is usually a report query written before Dapper arrived. Read the target framework first, then the code.

ADO.NET and EF Core injection

ADO.NET will execute whatever string you give it, and EF Core offers two raw-SQL methods whose names differ in safety by one word. FromSqlInterpolated and the interpolated overload of FromSql bind their arguments; FromSqlRaw does not, and passing it an interpolated string is the exact mistake it exists to allow.

public User Find(string name)
{
    var cmd = new SqlCommand(
        "SELECT * FROM Users WHERE Name = '" + name + "'", connection);
    return Read(cmd);
}

// EF Core escape hatch, same defect
db.Users.FromSqlRaw("SELECT * FROM Users WHERE Name = '" + name + "'");

public User Find(string name)
{
    var cmd = new SqlCommand(
        "SELECT * FROM Users WHERE Name = '" + name + "'", connection);
    return Read(cmd);
}

// EF Core escape hatch, same defect
db.Users.FromSqlRaw("SELECT * FROM Users WHERE Name = '" + name + "'");

public User Find(string name)
{
    var cmd = new SqlCommand(
        "SELECT * FROM Users WHERE Name = @name", connection);
    cmd.Parameters.Add("@name", SqlDbType.NVarChar, 100).Value = name;
    return Read(cmd);
}

// EF Core: parameterised interpolation, not concatenation
db.Users.FromSql($"SELECT * FROM Users WHERE Name = {name}");

public User Find(string name)
{
    var cmd = new SqlCommand(
        "SELECT * FROM Users WHERE Name = @name", connection);
    cmd.Parameters.Add("@name", SqlDbType.NVarChar, 100).Value = name;
    return Read(cmd);
}

// EF Core: parameterised interpolation, not concatenation
db.Users.FromSql($"SELECT * FROM Users WHERE Name = {name}");

Two details worth checking beyond the obvious concatenation: string parameters bound without a size (which lets the server truncate or pad and defeats some query plans), and ORDER BY clauses assembled from a column name taken from the request, which cannot be parameterised and needs an allowlist.

Deserialization

BinaryFormatter was removed in .NET 9. In .NET 9 and later the type still exists so old code compiles, but every call throws PlatformNotSupportedException, and the compatibility switch that used to re-enable it is gone. That means the classic "BinaryFormatter deserialization" finding is now almost always one of two things: a .NET Framework 4.8 project, or a project referencing the System.Runtime.Serialization.Formatters compatibility package on an older runtime.

The live risk on modern .NET is Newtonsoft.Json with TypeNameHandling enabled. It reads type names from the payload and constructs them, which is the same primitive BinaryFormatter provided. System.Text.Json is safe by default and only becomes risky when a polymorphic converter is added without a type allowlist.

// types from the payload are honoured
var settings = new JsonSerializerSettings
{
    TypeNameHandling = TypeNameHandling.All
};
var obj = JsonConvert.DeserializeObject<Payload>(json, settings);

// types from the payload are honoured
var settings = new JsonSerializerSettings
{
    TypeNameHandling = TypeNameHandling.All
};
var obj = JsonConvert.DeserializeObject<Payload>(json, settings);

// types are resolved through an allowlist binder
var settings = new JsonSerializerSettings
{
    TypeNameHandling = TypeNameHandling.None,
    SerializationBinder = new AllowlistBinder(
        typeof(Payload), typeof(Address))
};
var obj = JsonConvert.DeserializeObject<Payload>(json, settings);

// types are resolved through an allowlist binder
var settings = new JsonSerializerSettings
{
    TypeNameHandling = TypeNameHandling.None,
    SerializationBinder = new AllowlistBinder(
        typeof(Payload), typeof(Address))
};
var obj = JsonConvert.DeserializeObject<Payload>(json, settings);

XML and path handling

XXE in .NET is a configuration question. XmlDocument and XmlReader honour DTDs when DtdProcessing is enabled and an XmlResolver is present; the safe configuration sets DtdProcessing.Prohibit and a null resolver. Since the framework defaults changed, a finding here usually means an explicit setting someone added to "make the legacy feed work".

Path traversal survives in .NET because Path.Combine has two behaviours that look alike: it returns the second argument untouched when that argument is rooted, and it does not normalise. A StartsWith check on the combined string therefore passes for a traversal, and fails for a legitimate sibling directory whose name shares a prefix — C:\data\public2 starts with C:\data\public.

// the user controls the whole path
var file = Path.Combine(root, Request.Query["name"]);
return PhysicalFile(file, "application/octet-stream");

// and a check that looks like containment but is not
if (!file.StartsWith(root)) throw new Exception("blocked");

// the user controls the whole path
var file = Path.Combine(root, Request.Query["name"]);
return PhysicalFile(file, "application/octet-stream");

// and a check that looks like containment but is not
if (!file.StartsWith(root)) throw new Exception("blocked");

var requested = Request.Query["name"].ToString();
var full = Path.GetFullPath(Path.Combine(root, requested));
var rootFull = Path.GetFullPath(root) + Path.DirectorySeparatorChar;

// compare on the normalised path, with a separator boundary
if (!full.StartsWith(rootFull, StringComparison.OrdinalIgnoreCase))
    throw new UnauthorizedAccessException("outside root");

return PhysicalFile(full, "application/octet-stream");

var requested = Request.Query["name"].ToString();
var full = Path.GetFullPath(Path.Combine(root, requested));
var rootFull = Path.GetFullPath(root) + Path.DirectorySeparatorChar;

// compare on the normalised path, with a separator boundary
if (!full.StartsWith(rootFull, StringComparison.OrdinalIgnoreCase))
    throw new UnauthorizedAccessException("outside root");

return PhysicalFile(full, "application/octet-stream");

Authorisation

ASP.NET Core authorises by default only if you configure a fallback policy. Without one, an action with no attribute is anonymous, and the defect is invisible in the controller — the file looks ordinary. The audit is two steps: find the fallback policy in Program.cs, then check every action that opted out.

[ApiController]
[Route("api/documents")]
public class DocumentsController : ControllerBase
{
    // no [Authorize]: the global fallback decides, and it is not configured
    [HttpGet("{id}")]
    public async Task<IActionResult> Get(int id)
        => Ok(await db.Documents.FindAsync(id));
}

[ApiController]
[Route("api/documents")]
public class DocumentsController : ControllerBase
{
    // no [Authorize]: the global fallback decides, and it is not configured
    [HttpGet("{id}")]
    public async Task<IActionResult> Get(int id)
        => Ok(await db.Documents.FindAsync(id));
}

[ApiController]
[Authorize]
[Route("api/documents")]
public class DocumentsController : ControllerBase
{
    [HttpGet("{id}")]
    public async Task<IActionResult> Get(int id)
    {
        var doc = await db.Documents.FindAsync(id);
        if (doc is null) return NotFound();

        // resource authorisation: the caller must own this document
        var userId = User.FindFirstValue(ClaimTypes.NameIdentifier);
        if (doc.OwnerId != userId) return Forbid();
        return Ok(doc);
    }
}

[ApiController]
[Authorize]
[Route("api/documents")]
public class DocumentsController : ControllerBase
{
    [HttpGet("{id}")]
    public async Task<IActionResult> Get(int id)
    {
        var doc = await db.Documents.FindAsync(id);
        if (doc is null) return NotFound();

        // resource authorisation: the caller must own this document
        var userId = User.FindFirstValue(ClaimTypes.NameIdentifier);
        if (doc.OwnerId != userId) return Forbid();
        return Ok(doc);
    }
}

Resource-based authorisation belongs inside the handler or in an IAuthorizationHandler that receives the resource. A policy that checks a role proves the caller may use the endpoint; it never proves this row is theirs.

Crypto and secrets

The recurring defects are SHA256 with a hand-rolled salt used for passwords, AES in CBC mode with a static IV, and secrets in appsettings.json or in a user secret that shipped to production. Configuration should come from Azure Key Vault, AWS Secrets Manager or environment variables injected at deploy; a connection string with a password in appsettings.json is a finding regardless of whether the repository is public.

Evidence Collection

False Positive Identification

C# and .NET Review Checklist

Fixing What You Found