Securing your ELMAH log (Error Logging Modules and Handlers) is a subject that has been touched upon in multiple presentations and blog posts. ELMAH itself even provides some great documentation, but questions on the subject still pop up on Stack Overflow on a regular basis. I believe there's room for some extended documentation, giving you the full picture of the options available. This post is my attempt to demystify ELMAH security.

ELMAH comes with a couple of features for adding security to your logs out of the box. Basically, they all focus around securing access to the URL /elmah.axd added automatically as part of the installation through NuGet.

The Security Element

The security element located beneath the elmah element provides a single attribute namedallowRemoteAccess:

By default, remote access to /elmah.axd isn't allowed, meaning that requesting that URL on everything else other than localhost returns an HTTP status code 403. It is not recommended to open up remote access to the ELMAH UI, but in some situations, it may make sense. Setting allowRemoteAccess to 1 or true, makes /elmah.axdaccessible on your public facing website.

Access Through ASP.NET Authorization

So, if the default setting is not able to access /elmah.axd, how do you browse your error logs? Well, in fact, combining remote access with ASP.NET authorization rules is your friend. When installing ELMAH, configuration for the elmah.axd URL where added to your web.config file:

<location path="elmah.axd" inheritInChildApplications="false">
  <system.web>
    <httpHandlers>
      <add verb="POST,GET,HEAD" path="elmah.axd" type="Elmah.ErrorLogPageFactory, Elmah" />
    </httpHandlers>
    <!-- 
      See http://code.google.com/p/elmah/wiki/SecuringErrorLogPages for 
      more information on using ASP.NET authorization securing ELMAH.

    <authorization>
      <allow roles="admin" />
      <deny users="*" />  
    </authorization>
    -->
  </system.web>
  <system.webServer>
    <handlers>
      <add name="ELMAH" verb="POST,GET,HEAD" path="elmah.axd" type="Elmah.ErrorLogPageFactory, Elmah" preCondition="integratedMode" />
    </handlers>
  </system.webServer>
</location>

By default, the authorization-element is commented out. If you remove the comment around that element, you will get a default security setup where admin users will be allowed access to /elmah.axd only. This is configured through the allow and deny elements:

<authorization>
  <allow roles="admin" />
  <deny users="*" />  
</authorization>

If you want to allow a list of users only, there's a users attribute available on the allow-element as well:

<authorization>
  <allow users="Thomas,Jesper" />
  <deny users="*" />  
</authorization>

What About ASP.NET MVC?

ELMAH was originally created for ASP.NET. Different features available in ASP.NET MVC have been causing a lot of head-scratching since it was introduced back in 2007. Some of you may have struggled with MVC's HandleErrorAttribute, as well as getting custom errors and ELMAH working at the same time. In 2011, Alexander Beletsky created the Elmah.MVC package to help MVC developers using ELMAH. We highly recommend MVC projects use this package since it removes a lot of the frustrations that people are having with MVC and ELMAH.

To configure remote access to ELMAH using the Elmah.MVC, you will need to add a couple of application settings:

<appSettings>
    <add key="elmah.mvc.requiresAuthentication" value="true" />
    <add key="elmah.mvc.allowedRoles" value="Admin" />
    <add key="elmah.mvc.allowedUsers" value="Thomas" />
</appSettings>

The example above allows users with the role Admin as well as the user name Thomas to access the ELMAH UI (located on /elmah as default when using Elmah.MVC).

Would Your Users Appreciate Fewer Errors?

elmah.io is the easy error logging and uptime monitoring service for .NET. Take back control of your errors with support for all .NET web and logging frameworks.

This article first appeared on the elmah.io blog at https://blog.elmah.io/elmah-security-and-allowremoteaccess-explained/