Ref: Wikipedia - Defence in depth
Likewise, in information security or Information Assurance defence in depth represents the use of multiple computer security techniques to help mitigate the risk of one component of the defence being compromised or circumvented. An example could be anti-virus software installed on individual workstations when there is already virus protection on the firewalls and servers within the same environment. Different security products from multiple vendors may be deployed to defend different potential vectors within the network, helping prevent a shortfall in any one defence leading to a wider failure; also

DotNetNuke practices a defence in depth process to ensure that common internet security issues are mitigated. Examples of this include:

• HttpOnly attribute - DotNetNuke applies this attribute to all cookies -the HttpOnly attribute directs browsers to use cookies via the HTTP protocol only. An HttpOnly cookie is not accessible via non-HTTP methods, such as calls via JavaScript (e.g., referencing "document.cookie"), and therefore cannot be stolen easily via cross-site scripting attacks. More detail on HttpOnly cookies can be found here

• Viewstateuserkey - DotNetNuke applies this setting to help you prevent attacks on your application from malicious users. It does this by allowing you to assign an identifier to the view-state variable for individual users so that they cannot use the variable to generate an attack. Further details can be read here

• enableEventValidation - DotNetNuke sets this property to true which forces ASP.NET to validate that a control event originated from the user interface that was rendered by that control, which foils attempts to do POSTBACK based attacks or to alter control contents via javascript hacking/HTTP Proxies. A control registers its events during rendering and then validates the events during postback or callback handling. For example, if a list control includes options numbered 1, 2, or 3 when the page is rendered, and if a postback request is received specifying option number 4, ASP.NET raises an exception. All event-driven controls in ASP.NET use this feature by default.

• viewStateEncryptionMode - this value is set to Always by DotNetNuke. Whilst this adds a small overhead to each page request, this does mean that users cannot decode the viewstate and inspect the details (many modules use viewstate to store temporary copies of sensitive information). This value, in concert with enableViewStateMac being set to true, also means that viewstate entries cannot be hacked or spoofed.

• DotNetNuke itself and all the core modules exclusively use stored procedures which means that SQL Injection is not an issue. Note: the core reports module does allow for dynamic sql so care should be taken with it - other third party grid/reports modules may also use dynamic sql so should be carefully evaluated.