Securing Your InstantForum Installation

This article offers general best practices & guidance to help you secure your InstantForum community.

We recognize communities are often a valuable target for attackers and have invested heavily to ensure our software is as secure as possible. InstantForum follows many security best practices to help protect against common attacks such as XSS, SQL Injection, CSRF & session hijacking,. InstantForum also uses proven standard authentication mechanisms and supports ASp.NET forms authentication, windows authentication (with our Active Directory module) & the newer ASP.NET Identity / OWIN middleware based authentication,

There are a few deployment options beyond our control that may help you further secure your InstantForum installation. This article should help you ensure your InstantForum installation is as secure as possible.

Change the Default Admin Credentials

It's extremely important after you've installed InstantForum for the first time you reset the default administrator credentials. We would strongly suggest using a complex password for your administrator account.

Ensure Custom Errors Are Enabled

It's important if the unexpected happens users do not see detailed error messages that may be produced by InstantForum. To ensure sensitive details are never presented to end users. Please ensure the InstantForum web.config has custom errors enabled like so...

<customErrors mode="RemoteOnly" defaultRedirect="ErrorPage.aspx">
  <error statusCode="403" redirect="ErrorPage.aspx" />
  <error statusCode="404" redirect="ErrorPage.aspx" />
  <error statusCode="500" redirect="ErrorPage.aspx" />

Consider SSL / TLS for your installation

To secure all communication between your clients and server we would suggest using a SSL certificate for your installation whenever possible. InstantForum fully supports SSL, We use relative paths for all external resources (CSS / JS) ensuring external content is served over the same protocol as the requested page.

To force all links within InstantForum to use SSL if a user visits a non SSL version of your installation we would suggest hard coding the SSL version of your URL within your InstantForum database. Please follow the steps below to hard code your application URL...

  1. Visit the InstantForum Admin CP
  2. Click General Settings on the Left
  3. Locate the Application URL text box on the General Settings page
  4. Provide the full absolute URL to your installation ensuring you use https within the Application URL textbox. For example "".

If your force all traffic over HTTPS you should also set requireSSL="true" within your InstantForum web.config as shown below...

    <authentication mode="Forms">
<forms name="InstantASP" requireSSL="true" cookieless="UseCookies" loginUrl="Logon.aspx" protection="All" slidingExpiration="true" path="/" />

Upgrading Insecure Requests

You can add custom headers to the InstantForum web.config to automatically upgrade insecure requests to secure requests. This is shown below...

    <!-- Upgrade insecure requests to secure requests   -->
    <add name="Content-Security-Policy" value="upgrade-insecure-requests" />
    <add name="Strict-Transport-Security" value="max-age=31536000; includeSubDomains; preload" />
    <add name="Upgrade-Insecure-Requests" value="1" />
    <add name="Vary" value="Upgrade-Insecure-Requests" />  

Removing X-AspNet-Version & X-Powered-By headers

You can optionally remove identifying response headers by modifying the web.config file like so...

    <remove name="X-Powered-By" />
    <remove name="X-AspNet-Version" />

Run outside of frames

To ensure the application cannot run within an IFrame or frameset please add or update the following application setting within your web.config file...

    <add name="X-Frame-Options" value="DENY" />    

Content Security Policy

The content security policy header helps to prevent code injection attacks like cross-site scripting and clickjacking, by telling the browser which dynamic resources that are allowed to load. The example below shows how to ensure resources are only ever able to load from the same origin as the page serving the request...

      <add name="Content-Security-Policy" value="default-src 'self'" />

Consider SSL / TLS for your SMTP server

To secure all communicate between InstantForum and your SMTP server we would suggest enabling SSL / TLS for SMTP whenever possible. For further information on how to enable SSL for your SMTP server please refer to Configuring Outbound InstantForum Emails.

Login Via Email Over Username

InstantForum allows you to choose which detail alongside a password a user must provide during the login process From the InstantForum Admin CP > Manage Settings > Login & Registration Settings page locate the "Login Using" drop down list and you will notice you can choose from either Email Address or Username. This lets you set as an administrator how users login. For example a user can enter a email address & password or a username & password to authenticate within InstantForum.

For external public installations we would strongly suggest you use the Email Address option for user authentication. A users email address is never displayed to other users whilst a users username is displayed to other users.

We provide the ability to login using your username mainly for internal / private installations or installations that are integrated into our InstantForum Active Directory Module. As the username is displayed publicly within the forum we would not suggest using the username for login unless you can control access to your InstantForum installation.

Minimize Attack Surface

If's good practice to minimize the possible vectors attackers could use. For example we would suggest disabling features such as PHP or FTP on your web server. PHP is not needed for InstantForum and if enabled this has it's own set of security risks.

If you need to enable FTP for access to your InstantForum installation we would strongly suggest using SFTP and leveraging a IP white list for connections to your FTP site.

IIS Modules / Handler Mappings

This again minimizes the attack surface. Consider disabling any custom or 3rd party handler mappings within IIS that are not related to serving ASP.NET content or static resources.

Install only the IIS modules you need

IIS 8 is composed of more than 40 modules, which allow you to add modules you need and remove any modules you don’t need. If you install only the modules you need, you reduce the surface area that is exposed to potential attacks.

Periodically remove unused or unwanted modules and handlers.

Look for modules and handlers that you no longer use and remove them from your IIS installation. Strive to keep your IIS surface area as small as possible.