How to Fix Insecure Deserialization in ASP.NET
Learn how to prevent and fix Insecure Deserialization vulnerabilities in ASP.NET applications. Step-by-step guide with code examples, security checklists, and best practices.
What Is Insecure Deserialization?
Insecure Deserialization occurs when an application deserializes (converts from a stored/transmitted format back to an object) data from untrusted sources without adequate validation. The vulnerability allows attackers to manipulate serialized objects to change application logic, execute arbitrary code, or escalate privileges.
While traditional deserialization attacks (Java, Python pickle, PHP unserialize) focus on exploiting language-specific object reconstruction to achieve remote code execution, JavaScript applications are also vulnerable through different vectors. JSON deserialization can be exploited through prototype pollution (injecting `__proto__` properties), manipulation of type fields used for polymorphic deserialization, and tampering with signed but not encrypted data (like JWTs where the signature is not properly verified).
In modern web applications, insecure deserialization commonly manifests as: trusting client-side state (form fields, cookies, hidden inputs) without server-side validation; using `eval()` or `Function()` to process serialized data; accepting and processing arbitrary object shapes from API requests; and using YAML.load() (unsafe by default in many libraries) instead of YAML.safeLoad(). GraphQL APIs that accept complex nested input objects are also susceptible to deserialization-based attacks.
Why It Matters
Insecure deserialization can lead to the most severe attack outcomes. In languages with rich object graphs (Java, Python, .NET), it directly enables remote code execution. In JavaScript applications, it can lead to prototype pollution affecting all objects in the application, privilege escalation by manipulating role or permission fields in serialized state, denial of service through deeply nested or circular object structures, and data tampering by modifying serialized state that the application trusts. The impact depends on what the application does with the deserialized data, but it frequently leads to complete application compromise.
How to Fix It in ASP.NET
Never trust serialized data from untrusted sources. Implement integrity checks (HMAC signatures) on all serialized data that crosses trust boundaries. Use strict schema validation (Zod, Yup, JSON Schema) on all incoming data before processing. Avoid using `eval()`, `Function()`, or `new Function()` to parse data. For JavaScript, freeze prototypes and use `Object.create(null)` for dictionaries to prevent prototype pollution. Use type-safe deserialization that only accepts expected shapes. Validate and sanitize all nested object properties. Implement input size limits on serialized data. Use `JSON.parse()` for JSON (safe) rather than `eval()` (dangerous). For YAML, always use safe loading functions.
ASP.NET-Specific Advice
- Razor syntax auto-encodes output by default. Never use `@Html.Raw()` with unsanitized user content.
- Use Entity Framework with LINQ queries or parameterized SQL. Never use string interpolation in `FromSqlRaw()` calls.
- ASP.NET includes anti-forgery token validation. Use `[ValidateAntiForgeryToken]` on all POST actions and include `@Html.AntiForgeryToken()` in forms.
- Use Data Annotations (`[Required]`, `[StringLength]`, `[RegularExpression]`) and `ModelState.IsValid` for input validation.
ASP.NET Security Checklist for Insecure Deserialization
ASP.NET Security Best Practices
Razor syntax auto-encodes output by default. Never use `@Html.Raw()` with unsanitized user content.
Use Entity Framework with LINQ queries or parameterized SQL. Never use string interpolation in `FromSqlRaw()` calls.
ASP.NET includes anti-forgery token validation. Use `[ValidateAntiForgeryToken]` on all POST actions and include `@Html.AntiForgeryToken()` in forms.
Use Data Annotations (`[Required]`, `[StringLength]`, `[RegularExpression]`) and `ModelState.IsValid` for input validation.
Use ASP.NET Identity for authentication with proper password hashing (PBKDF2 by default). Never implement custom password storage.
Configure HTTPS redirection and HSTS in `Program.cs`. Use `app.UseHttpsRedirection()` and `app.UseHsts()` in production.
Use `[Authorize]` attributes and policy-based authorization for route-level and action-level access control.
Implement rate limiting using ASP.NET Core's built-in `RateLimiter` middleware (available from .NET 7+).
Scan Your ASP.NET App with SafeVibe
Stop guessing if your ASP.NET app is vulnerable to Insecure Deserialization. Run an automated penetration test in minutes and get actionable results.
Start Free Scan