Model Inversion in Aspnet (Csharp)

Model inversion in ASP.NET applications using C# occurs when an API endpoint exposes server-side data models or internal object structures directly to the client, enabling attackers to infer sensitive information about the application’s architecture, data types, and business logic. In C# ASP.NET, this commonly arises when JSON serialization returns full domain entities or when reflection-based serializers like System.Text.Json or Newtonsoft.Json include type information, property names, and relationships without filtering.

For example, an endpoint returning a C# class such as ApplicationUser might inadvertently expose fields like PasswordHash, TwoFactorEnabled, or navigation properties that reveal database schema details. Attackers can use these insights to perform privilege escalation or data exfiltration by manipulating input to access related objects or collections. MiddleBrick’s checks for BOLA/IDOR and Property Authorization help detect when responses expose model-specific details that should be abstracted.

Serialization behavior in C# is a key enabler. By default, serializers may include type metadata (e.g., via $type in JSON) or retain public properties that map directly to database columns. When combined with over-permissive endpoint designs—such as accepting an ID and returning the corresponding entity without proper authorization checks—the API effectively hands an attacker a blueprint of the data model. This is especially risky in CRUD scenarios where endpoints follow predictable patterns like /api/users/{id}.

Compliance frameworks such as OWASP API Top 10 highlight this as a critical risk when sensitive data exposure occurs through indirect means. Real-world cases have shown that attackers chain model inversion with IDOR to access other users’ records or administrative configurations. MiddleBrick’s OpenAPI/Swagger analysis, with full $ref resolution, cross-references runtime responses against spec definitions to identify unexpected model exposure.

Unlike static analysis, middleBrick performs black-box scanning against the running endpoint, detecting actual serialization output and identifying whether C# model properties are being exposed. This approach uncovers issues that code reviews might miss, particularly in complex object graphs involving inheritance or nested collections. The scanner’s checks for Data Exposure and Property Authorization are designed to surface these risks without requiring authentication or source code access.

To mitigate model inversion in ASP.NET with C#, apply strict data transfer object (DTO) patterns and control JSON serialization settings. Avoid returning domain entities directly from controllers. Instead, define dedicated DTOs that include only the necessary properties, and map between layers using tools like AutoMapper or manual projection.

Example: Secure DTO Usage in ASP.NET Core

// Domain model (not exposed via API)
public class ApplicationUser
{
    public Guid Id { get; set; }
    public string Username { get; set; }
    public string PasswordHash { get; set; }
    public bool TwoFactorEnabled { get; set; }
    public ICollection Roles { get; set; }
}

// DTO for safe exposure
public class UserProfileDto
{
    public Guid Id { get; set; }
    public string Username { get; set; }
    public DateTime CreatedAt { get; set; }
}

// Controller using explicit mapping
[ApiController]
[Route("api/users")]
public class UsersController : ControllerBase
{
    private readonly IUserService _userService;

    public UsersController(IUserService userService)
    {
        _userService = userService;
    }

    [HttpGet("{id:guid}")]
    public ActionResult<UserProfileDto> GetUser(Guid id)
    {
        var user = _userService.GetUserById(id);
        if (user == null) return NotFound();

        var dto = new UserProfileDto
        {
            Id = user.Id,
            Username = user.Username,
            CreatedAt = user.CreatedAt
        };

        return Ok(dto);
    }
}

Additionally, configure JSON serialization to avoid leaking type information. In Program.cs, disable metadata inclusion and use contract resolver settings to limit exposed properties.

Example: JSON Serialization Configuration

// Program.cs
builder.Services.AddControllers()
    .AddJsonOptions(options =>
    {
        // Prevent inclusion of $type metadata in JSON output
        options.JsonSerializerOptions.TypeInfoResolver = null;

        // Optionally, use camelCase to reduce predictability
        options.JsonSerializerOptions.PropertyNamingPolicy = JsonNamingPolicy.CamelCase;

        // Ignore null values to reduce data footprint
        options.JsonSerializerOptions.DefaultIgnoreCondition = JsonIgnoreCondition.WhenWritingNull;
    });

// Explicitly ignore sensitive properties via attributes
public class ApplicationUser
{
    public Guid Id { get; set; }
    public string Username { get; set; }

    [JsonIgnore]
    public string PasswordHash { get; set; }

    [JsonIgnore]
    public bool TwoFactorEnabled { get; set; }
}

For endpoints involving sensitive operations, enforce property-level authorization checks before constructing responses. Combine this with input validation to prevent ID manipulation attacks that could lead to unauthorized data access.

Example: Property Authorization in Action

[HttpGet("{id:guid}/profile")]
public ActionResult<UserProfileDto> GetUserProfile(Guid id)
{
    var currentUserId = GetCurrentUserId();
    if (id != currentUserId)
    {
        return Forbid(); // Or return StatusCode(403)
    }

    var user = _userService.GetUserById(id);
    var dto = new UserProfileDto
    {
        Id = user.Id,
        Username = user.Username
    };

    return Ok(dto);
}

These practices reduce the attack surface by ensuring that only intended data structures are serialized and returned. MiddleBrick’s scans can validate that such mitigations are effective by checking whether responses still contain model-specific fields or excessive metadata.