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.