[I retitled this post. Admittedly the original idea was a little hairbrained... It was too early in the morning, I was contemplating a problem that is mentioned in the comments, and quite frankly I hadn't fully thought through everything... I will leave the rest of the post alone (and the comments)... just be aware that scoping the class doesn't make it anymore secure. It does make it better architected which means that you probably have the right mindset].
I have recently been considering that better scoping of my classes (and their proeprties/methods) may make my code a little more secure. I'm not talking about protected, private, and public. I'm talking about Friend and internal. I suspect that someone will probably correct me on some aspect of this (I'm sure I don't have it all figured out). First of all let me show you how I used to set up my database layer.
Public Class DBInfo
Protected Shared _DSN as String = ""
Public Shared Function GetConnectionString() as String
If _DSN.Length = 0 Then
_DSN = GetDSN()
End If
Return _DSN
End Function
Private Shared Function GetDSN() as String
' Actual Implementation deleted
End Function
End Class
Public Class sqlBase() ' All database modules are derived from this class
Protected Property ConnectionString() as String
Return DBInfo.GetConnectionString()
End Property
End Class
As you can see I don't use Friend at all. So what could happen. The simple thing is that someone could simply reference my assembly and either derive a new class from sqlBase (and then could easily get the connection string out of the database). Someone could also just reference the assembly and call the DBInfo class directly. Now they have the connection string to the database. By using "Friend" instead of "Public" we make the methods only callable from within the assembly. If I change all the "Public" statements to "Friend" in the above example, I ensure that only my assembly can retrieve the connection string (which in my mind is always encrypted). BTW, in C# "internal" is the keyword you would use instead of "Friend".
Obviously you want to think about what you might want to allow to be callable from outside your assemblies and use public for these things. I actually am starting to think in the opposite direction which is to say, which methods/properties/classes contain info that should be kept private to this assembly (obviously ConnectionStrings fall into this category). This probably makes things a little less secure, but it's easier for me to think about the items that need secured instead of trying to predict what I want to use from outside this assembly.
Of course reflection messes all this up because if an assembly has enough rights it can simply interrogate the class and call any method (including private ones). But at least with using Friend you force a hacker to go to level (and remember they still have to figure out how to execute code on the box where your app is deployed).
[For those who read this article as it was originally published using the word "virtual" instead "internal" please forgive me. When I was learning the various C# scoping keywords, someone told me that "Friend" is "internal" in C#... I heard "virtual" instead of "internal" and have yet to get it out of my head. If I had written C# code I would have caught it... Also, I caught this about 1/2 way to work, so I couldn't wait to get here to correct... wouldn't you know that I caught every light?].