5 Essential Things to Check out before Your Site Goes Live
Your site is developed and tested. It´s time to deploy it to a production server and launch it. Before you do that, please read the following top five hints, which will help you keep the site running and avoid security issues.
Disable/delete all test user accounts
Every sample Kentico CMS site contains some sample users after import. These can log into the site without any password. Their purpose is to easily demonstrate the functionality of
Kentico CMS and they are not meant to be used in production environment. The administrator account doesn’t have any password specified by default either.. I’m also convinced that most of you create your own test users with blank passwords during development. All these accounts must be either disabled, deleted or a password must be set up for them. All users without a password are listed in
CMSDesk/SiteManager with a warning sign in the
Actions area.
Make sure that directories cannot be listed
Kentico
CMS contains certain directories, such as
~/CMSSiteUtils/Export, which mustn’t show its content to public users. These directories may contain sensitive information. In this particular case,
~/CMSSiteUtils/Export is the default directory for site export. The site export may contain user names and passwords and you sure don’t want to give this information to the rest of the world, do you?
In general, you should deny listing for all directories and allow it only for the needed ones.
Turn off debug, trace and set up custom error pages
ASP.NET debug and tracing or Kentico CMS debug, all of these are a great source of information for developers. But once you move your web application to a production environment, you must hide it. Why? This data can help hackers a lot to attack your site. You can of course log the debug information into a file or show errors to the client connected from localhost, but do not make them available to public users.
ASP.NET debug and tracing can be disabled in the web.config file and there is also the <CustomErrors> section, where you can specify pages for handling different HTTP error statuses.
Configure encrypted connection (HTTPS)
In order to configure HTTPS (SSL) for a web application, you need to configure IIS first (or let a provider do that). More information about configuration of IIS can be found in
IIS official documentation. Be aware that self-signed certificates aren’t very much secure because they allow the “
Man in the middle” attack. If you take security seriously you should always use a certificate generated by a certificate authority. Details how to configure HTTPS in Kentico CMS can be found in the
Developer’s Guide.
Encrypt sections with sensitive data in web.config
You may remember the
padding oracle vulnerability in ASP.NET found last year. Your web.config can be compromised and you should encrypt at least the sections with connection strings. This feature is built-in in ASP.NET. I found a really nice
blog post which describes how to do that.
I don’t say that these five hints are the only ones you should take care of but from my point of view these are the most critical. Do you know anything more important? Please let me know in comments.