I just read an article on MSDN about reasons for declaring classes as sealed. In the last paragraph, Eric Lippert says:

4) Secure. the whole point of polymorphism is that you can pass around objects that look like Animals but are in fact Giraffes. There are potential security issues here.

I tried to look on the Google about this topic, but I didn't manage to find anything other that OOP tutorials, so if anybody could point me in the right direction where to look, or even say a few words on this topic, it would be great.



2 Answers 2


In terms of class/member access I would say "security" is more about API security. When you publish code that is fairly open, others may end up using your code in ways you did not intend, that make it harder for you to make internal, non-breaking changes in the future.

While some of the choices you make in OOP class/member access may influence your overall system security from external attacks, those choices are not strongly related to security from those type of attacks. Once you are already sharing program execution space, in most cases the other program can really do almost anything it wants to do, in some way or other. (For example, private members in Java can be accessed through reflection quite easily via setAccessible.)

When developing APIs, those kind of hacks are never supported by the library author, so they are "use at your own risk". With a good field/class access strategy, APIs can be refactored extensively with few external API breakages.

I tracked down the article that you are referring to, and the context helps illuminate this issue.

Point three is actually related to my original answer above:

  1. Compatible. If in the future I discover that I should have sealed a class, I'm stuck. Sealing a class is a breaking change. If I discover that I should have left a class unsealed, unsealing in a future version is a non-breaking change. Sealing classes helps maintain compatibility.

The next bullet point is your original quote:

  1. Secure. the whole point of polymorphism is that you can pass around objects that look like Animals but are in fact Giraffes. There are potential security issues here.

Following on helps illuminate the problems that Eric is referring to:

Every time you implement a method which takes an instance of an unsealed type, you MUST write that method to be robust in the face of potentially hostile instances of that type. You cannot rely upon any invariants which you know to be true of YOUR implementations, because some hostile web page might subclass your implementation, override the virtual methods to do stuff that messes up your logic, and passes it in. Every time I seal a class, I can write methods that use that class with the confidence that I know what that class does.

In this case, Eric is clearly referring to cases when a potentially hostile system is actually able to interact with your system with code. In that case, polymorphism does become an issue, since, as Eric says, when you make calls on the objects that are passed in, the object could be doing something you completely didn't intend it to do.

Sealing classes means that the object that is passed in cannot be subclassed in that way. Obviously there would be no need for this if your system is never going to interact with potentially hostile API callers. As my original answer said — often that is such a difficult security risk to manage in and of itself that is simply disallowed altogether.

  • I didn't know about term API security, I thought that he was thinking about what is called security in general. I will go and read something more about it, thank you for the directions. Jul 12, 2011 at 23:05
  • 1
    I actually expanded my answer after I found the original article. Updated now.
    – Nicole
    Jul 12, 2011 at 23:16
  • 1
    Developers use "for security reasons" the way politicians use "for the children". Early, often, and badly. Jul 12, 2011 at 23:59
  • 1
    Security is the wrong term for this... perhaps correctness is closer to the original intent. After all its just a restatement of the open closed principle.
    – CurtainDog
    Jul 13, 2011 at 1:11
  • 1
    @Renesis: I think you summarized it quite well, thanks! Jul 13, 2011 at 20:55

Let's say you create a security validation class, which is passed to your main form by an IoC. Because you use this structure for a few different systems, like a good little programmer you create a base class with most of the logic, and put system-specific code in the derived classes.

An attacker takes a look, and finds this Template Method pattern. He also sees that a key piece of the puzzle, a property "SecurityDBConnString", is abstract (because it's used by base class logic but can't be specified there as it's system-specific), and when you overrode it for the system he's interested in, you didn't seal it. The attacker fires up his cracked VS copy, derives his own class from yours, further overriding SecurityDBConnString to point to a system he controls, then modifies the IoC registrations to pass in his new class. Now he's in, and you're in trouble.

This would all have been much harder had you simply sealed your derived class or the overridden property within it. It would be harder still if you'd obfuscated your security library, but I digress; if you do not want anyone to derive your class, seal it. You will save yourself many headaches.

  • But, how can base class can be sealed? Should not that make impossible to have my own derived classes (which I would write for specific platforms)? Jul 12, 2011 at 23:17
  • 1
    The base class may not be able to be sealed, but it may have an internal constructor that can't be referenced by a derived class in another assembly, or it may have other features designed to make sure it is only derived by "in" people. When deriving it, you fulfill those security requirements, but by not sealing the derived class, your attacker can now piggyback on your object's good name to do bad things. That was the point.
    – KeithS
    Jul 12, 2011 at 23:31
  • Seems like the main problem here is that the attacker is a able to put their code on your system and modify the IoC registrations. If they can do that they can probably just replace your form with their own or replace your entire application with their own.
    – bdsl
    Jun 25 at 10:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.