Mari Jørgensen
Nov 11, 2010
visibility 6416
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
You’re not headless. You’re hybrid — and that’s the CMS 12 default.

For CMS 12 / Commerce teams with a React (or similar) storefront who keep hearing “just go headless” or “just move to Graph.” This is Part 1 of Fin...

Hanskumar Tripathi | Aug 13, 2026

Stott Security for Optimizely SaaS CMS

Introduction Stott Security  has been helping developers and editors manage Content Security Policies and security headers on  Optimizely PaaS CMS...

Mark Stott | Aug 13, 2026

Optimizely XML Resource Builder: A Visual Studio Extension for Language Resource Files

Anyone who has worked on a larger Optimizely solution will know the feeling. You add or update a page type, block type, or shared base class,

Adnan Zameer | Aug 13, 2026 |

Optimizely SaaS CMS Management API: The Write Side of Headless

Everything I’ve written in this series so far has been about reading content — Optimizely Graph, webhooks, ISR, caching layers. But at some point y...

Kiran Patil | Aug 12, 2026 |