New Community Website

Ordinarily, you'd be at the right spot, but we've recently launched a brand new community website... For the community, by the community.

Yay... Take Me to the Community!

Security best practices

Return to previous page

  • 4/7/2015



Security best practices

Last updated 9 years ago



(Enter the content of this article below)



Note: this wiki also contains other pages on Best practices

Module security

Secure module development
The purpose of this guide to assist the developer in ensuring the DotNetNuke modules they write are written with security in mind.

In this guide we will highlight common issues, and offer guidance on how to identify and
counter potential security issues that may occur whilst developing DotNetNuke modules.
In addition this document also covers general web security and recommended practices
such as defense in depth. “Defense in depth” is the principle of adding layers of
protection to defend against attempts by potential hackers. Whilst a hacker may be
skilled in certain areas such as SQL injection, they may not have the skills necessary to
break through a number of layers. If you code your modules so that they do not make any
assumptions, and validate their functionality at a number of levels, your modules will be
much more secure e.g. if you intend to write a module that allows file uploads, then it’s a
good idea to add code to validate the user and limit the type of files to a safe subset of
extensions, rather than assuming any call to this code can be trusted.

Hosting security

Hardening DotNetNuke Installations

The purpose of this guide to assist users in assessing how best to secure installations of
DotNetNuke. Due to the large amount of different environments in which DotNetNuke
can be deployed, it is not a prescriptive guide, but rather one that should help you
evaluate the settings that best fit for your deployments.

DotNetNuke has existing for a number of years now, and as with any evolving project,
some of this history has mandated particular decisions and scenarios. Some of these
areas can, with care, be hardened to provide a greater degree of protection against
potential attacks. In this guide we will cover both guidelines that can be followed for new
installations and guidelines that can be used to tighten up existing deployments.

Before you beginning planning DotNetNuke installs, you should ensure that you have
secured your servers, both IIS, and if used, SQL Server.

Do I really need to apply these steps?
That decision is of course up to you. DotNetNuke has had a number of security
penetration tests, by a number of different entities, with generally favorable results. Any
identified areas of potential weakness have been addressed, and now in many cases
multiple layers of blended security exist to counter common web application attacks.
However, diversity is always an admirable concept in security. Taking the time to harden
your installations, and make them different from vanilla installs is yet another layer of

This wiki has a number of pages that also cover this area:

Reporting an issue/contacting the security team

Please read the Security wikipage for contact details and links to useful additional information.

No sections defined
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out