Mari Jørgensen
Nov 11, 2010
visibility 6377
star star star star star
(3 votes)

Protect your plugins!

One of the things I love about EPiServer is how easy it is to extend. I’m sure that most of the EPiServer projects out there uses some kind of edit or admin plugin.

Attention2

What we see very often, is that these plugins are not under EPiServer authorization. In effect, If you know the url to the plugin .aspx, you can browse it directly anonymously!


So, how can we be sure that the plugins are secured?
Well, any of the solutions below should solve the problem.

Safest bet: Check access from code when aspx loads

protected override void OnInit(EventArgs e)
{
  base.OnInit(e);
  /// Making sure only administrators can reach this plugin
  if (!EPiServer.Security.PrincipalInfo.HasAdminAccess)
     AccessDenied();
}

This is a sample from an admin plugin. Your .aspx need to inherit from an EPiServer PageBase class (e.g. EPiServer.SimplePage) in order to use the AccessDenied method.

Using the location tag in web.config

<location path="EPiCode/ManageLanguages">
    <system.web>
      <authorization>
        <allow roles="WebAdmins, Administrators"/>
        <deny users="*"/>
      </authorization>
    </system.web>
  </location>

This is the same way EPiServer secures it’s admin and edit mode. Remember to add this section in all environments – development, test and especially at the production server. You can also place your plugin the same place as the EPiServer UI, but this complicates module packaging (as the UI paths will differ from project to project).

There is also the option of adding a web.config file at the same level as the .aspx file(s). An example implementation can be found here:  web.config for the EPiCode.PageTypeUtil module.

Important: Using the ICustomPlugInLoader interface (see description here) will not secure your aspx.

Use 5 minutes today to verify that your plugins are secure - this also includes any module plugins downloaded from CodePlex, EPiCode or the Code section on world.episerver.com.

Nov 11, 2010

Comments

Nov 11, 2010 10:32 AM

Great reminder and very important !

Magnus Rahl
Magnus Rahl Nov 11, 2010 10:34 AM

Very important - and often forgotten!

Per Nergård (MVP)
Per Nergård (MVP) Nov 11, 2010 11:06 AM

Aah always used the location element way. But doing it in code is so much nicer.

Nov 11, 2010 11:52 AM

Great post!
One way to solve the problem with putting the aspx/ascx in EPiServers UI-folder is to
have them embedded as resources and then register an appropriate VirtualPathProvider to deliver them from the edit/admin url.

tost
tost Nov 12, 2010 01:20 AM

Great post Mari, this is something that a lot of people forget.

error Please login to comment.
Latest blogs
Add more scheduled job settings from the Optimizely CMS 12 admin UI -- with OptiScheduledJob.ExtraParameters

  Optimizely (EPiServer) CMS 12 ships a great scheduled-jobs framework, but it has one frustrating gap: a job has nowhere to store its own...

Binh Nguyen Thi | Jun 25, 2026

Automated Search & Navigation to Graph Migration with Claude Code

A Claude Code plugin that scans your S&N codebase, applies Graph SDK transformations, and validates the result. Install once, run one command. CMS ...

Connor Fortin | Jun 24, 2026

Migrating from Find to Graph: Lessons Learned from a Real CMS 13 Project

While migrating a search solution from Optimizely Search & Navigation (Find) to Optimizely Graph in CMS 13, I encountered several issues that were...

Binh Nguyen Thi | Jun 24, 2026

Optimizely: Upgrade Opti-ID and .NET 10 in CMS 12

Many Optimizely customers are planning their roadmap around a future migration to Optimizely CMS 13. As a result, upgrades such as Opti ID adoption...

Madhu | Jun 23, 2026 |