I don't know enough about C#'s serialization to know whether it is a security risk, but I can tell you this: In Java, it is not safe to unserialize untrusted data. There are a number of subtle security pitfalls that can really screw you over. If you are guru-level, you can probably avoid the pitfalls, but an average developer probably has no clue about the dangers. Here are some examples of subtle points: * If you want to deserialize untrusted data, you have to write special deserialization code to defend against, e.g., [a malicious byte sequence that defeats your code's security invariant](http://www.oracle.com/technetwork/java/seccodeguide-139067.html#8). * If you do any security checks in your constructor or factory methods, [you have to duplicate them in special deserialization methods](http://www.oracle.com/technetwork/java/seccodeguide-139067.html#8). If you call the SecurityManager in the constructor or factory methods, you have to replicate those calls in a special deserialization method. * There have been [obscure security vulnerabilities](http://slightlyrandombrokenthoughts.blogspot.com/2008/12/calendar-bug.html) associated with how deserialization was used in Java standard library classes. And then [some more](http://slightlyrandombrokenthoughts.blogspot.com/2010/04/java-rmiconnectionimpl-deserialization.html). And [yet more](http://slightlyrandombrokenthoughts.blogspot.com/2011/03/oracle-java-applet-clipboard-injection.html). And [even more](http://slightlyrandombrokenthoughts.blogspot.com/2011/06/java-6-update-26-is-out.html). Are you [bored](http://slightlyrandombrokenthoughts.blogspot.com/2010/04/mutable-inetaddress-socket-policy.html) yet [or](http://slightlyrandombrokenthoughts.blogspot.com/2010/02/java-se-security-part-iii-keys.html) would you like [another](http://blog.cr0.org/2009/05/write-once-own-everyone.html)? By the way, this example illustrates [subtle and dangerous interactions between deserialization and the Java permission model (based upon stack inspection)](http://slightlyrandombrokenthoughts.blogspot.com/2010/04/java-trusted-method-chaining-cve-2010.html). * There are some [crazy hairy security pitfalls](http://slightlyrandombrokenthoughts.blogspot.com/2010/08/breaking-defensive-serialization.html) associated with deserialization that (1) allow an attacker to mutate fields that should not have been mutable, or (2) allow an attacker to exploit concurrency/reentrancy bugs to break security-critical object invariants or learn secret values you shouldn't be able to learn, or (3) observe incompletely initialized objects (thereby allowing to mutate objects that were intended to be immutable). * Here are some more [insane risks with Java deserialization](http://slightlyrandombrokenthoughts.blogspot.com/2010/07/why-complexpowerful-is-bad-combination.html). If you fully understand all of that and can keep it in your head, you may be a good candidate to write secure deserialization code that can safely handle untrusted byte streams. On the other hand, if you are a mere mortal (like me) who throws up their hands in disgust at the whole thing, then it might be prudent to ensure that you never deserialize untrusted data. In the example you give of deserializing a cookie value, here is one plausible defense you could use to ensure you never deserialize an untrusted byte stream. When generating the cookie, you could compute a message authentication code (MAC) over the cookie name and value and append it to the cookie value. When receiving the cookie, you could check whether the MAC is valid. Your server would need to generate a random MAC key and store it securely, but it doesn't need to share this secret value with anyone else (other than all servers who are serving requests).