Use a custom domain name as a way to secure your Magento administrative panel

After this year 2015 full of security issues (SUPEE-6482, SUPEE-6285,SUPEE-6237, SUPEE-5994, SUPEE-5344) we have seen that there is many websites which only use the custom routing to hide the administrative panel; it means, back-offices are available from the front webservers with a string in URL as element to identify you wants to access to the admin panel.

And by default this string is admin, a not very difficult element to find :).

In this case, we are not very far from default behaviour, and everyone can access from your website to your back-office login form. And if you do not have admin accounts automatic locking (like the community edition does) you encounter risks of brute force logging attempts. And if someone earn back-office access, he will:

  • delete your customers accounts?
  • close your websites?
  • Spam your customers?
  • Install an incompatible module from Magento connect which will break your site?

All these can affect your brand image.

But there is some ways to make more secure the Magento admin panel. One of them, its to use a custom domain name for your back-office: it has the main advantage to allow you to customize security rules.

Just a few of configuration are required. You’ll find them bellow.

This article expect that

  • Your Magento webserver is hosted on a unix debian like operating system.
  • Your webserver is Apache.
  • Your Magento website is defined in the /etc/apache2/site-available/magento.conf file
  • Your back-office is available on the HTTP protocol.
  • For now, you access to your back-office from the URL.
  • You wants to move it to the URL

The Magento configuration inherit mechanism

Before talking about the procedure to switch your back-office to a custom admin URL, just few words about how Magento manage URLs.

Magento come with it’s own concepts, and one of them is the ability to manage multiples websites and their internationalization within stores views.

When you display a page on Magento, you are in a store view. If you try to load a configuration value from this view, Magento first check if you have defined something for this store view. If yes, it use this value. If not, it check if you have defined something for the related website. If not, it’ll use the value set for the global scope. A concept you probably already know if you use Magento.

Back-office is a particularity of this concept: even if back-office is a store view, there is no hierarchy: the configuration used by the back-office view are the values defined for the global scope.

Magento URLs are completely included in this configuration management:

  • admin URL is the URL defined on the scope default.
  • Your websites and stores views are the specificities defined for the related configurations levels.

So Magento configuration inherit mechanism offer everything to define a custom URL for your back-office. It should be a shame to do not use it. How can we migrate this configuration?

Configure a custom admin URL for your Magento back-office

Step 1: Ensure that your Magento front-office stores URLs does not use the configuration inherit mechanism

This step is required because if you still use the configuration inherit mechanism (eg: have just define the URLs on the global scope), when we’ll update the back-office URL your front office URLs will also be updated. it could be problematic 🙂

The configuration of the Magento URLs is managed differently for secure (http) and unsecure (https) part of your website. We start with the unsecure part.

1.1 – Ensure that your Magento unsecure store URL(s) does not use inherit configuration

1.1.1: Go to the Magento administrative panel which manage URLs configuration

This configuration panel is located in the System > Configuration > General > Web > Unsecure URL tab. You should see something like this:

Screenshot of the interface in the Magento administrative panel which allow to manage URLs of your websites and stores

1.1.2: Iterate on each store view configuration

On the top left of the page, you have the store view selector (the select box which allow to define on which store view you are currently editing the configuration). on my Magento, I have:
Screenshot of the selectbox which allow to choose on which scope we work

1.1.3: Uncheck the configuration values for your URLs

Check for each store views from this selectbox the configuration of your unsecure URLs: make sure that the “Use website” is unchecked like in the screenshot bellow.
Screenshot of the Magento admnistrative panel: checkbox allow to customize the scope you are updating
If not, uncheck it and save configuration.

Repeat this step for each of the store views available (in my case, en_uk, en_us, fr_fr and the french store view for the b2b website).

To check if everything is ok, flush the cache block from the administrative panel System > Cache Management and browse with your web browser all of your stores: your(s) catalog(s) must be still available(s).

Your websites and store views use now a dedicated configuration value for the unsecure URL.

1.2 – Ensure your secure store URLs does not inherit configuration

Repeat the steps 1.1.1, 1.1.2, and 1.1.3 for your secure URLs configuration (available from System > Configuration > General > Web > secure URL tab).

When you’ll finished, you can validate with your web browser (after flushing cache block cache mangement) that for each of your store views the customer accounts and checkouts are still available.

Step 2: Ensure that your Magento cookie policy is able to handle a new admin URL

Ok, now you do not use anymore the inherit mechanism for both http and https URLs. But it’s not yet finish with the configuration: for now, your cookie policy is able to handle both your front and back-office queries. But if we update our back-office domain name and leave the cookie policy as it, back-office could be unavailable. Wrong not?

We have to also update this domain name cookie configuration

This step is only required if you have for some of your store view(s) or website(s) defined a custom cookie domain. But by default, the cookie domain accept everything. If you have not updated it, you can go directly to step 3 but I think it’s however interesting to take time to check this configuration.

2.1 – Ensure that configuration for cookie domain for your front-office store views does not depends of the default cookie domain configuration

Go now in the menu System > Configuration > General > Web > Cookie Management and make sure that the value set for each store is like we have done for the URL management: For each store, uncheck the “use website” checkbox and save configuration.

Use a custom cookie domain for session cookie

We are now sure that our configuration for our front office store views is specific.

2.2 – Ensure that the cookie domain configuration for the admin is able to handle both new and current domain names

For the back-office scope (scope default), make sure to select a cookie domain value which is acceptable by both your new admin URL and your current URL: since we’ve not updated the admin configuration URL, we need to be able to browse back-office. And when we’ll update it, we must also be able to do it. If not, when we’ll update the admin URL, we won’t be able to connect to the back-office because session will not be available.

Cookie domain is configurable from the administrative panel on the fieldset General > Web > Session Cookie Management. Ensure that you’ll update configuration value for the default scope!

in this example we should set something like, witch match both and

If there is no shared domain name between current and the future back-office URL, you must set . as cookie domain. This is less secure, but it’ll work in each case.

After updating this configuration value, log out from back-office, close your browser, and log in a second time. You should still be able to browse back-office.

Step 3: Update Apache configuration to define your custom admin back-office URL

Now Magento is ready to accept a new URL for the back-office. Before setting this new value in Magento back-office, we have to update Apache configuration: if not, when we send a request to our webserver with the new URL, we’ll try to access to a webserver unknown by Apache and we have an unexpected answer.

A good starting point could be to copy your current front-office configuration file to a new one to define the specificities to the admin server:

root@your_web_server:~$ cp /etc/apache/sites-enabled/magento.conf /etc/apache/sites-available/magentoadmin.conf && sed "s|ServerName *|ServerName|g" --in-place='.bak' /etc/apache/sites-available/magentoadmin.conf && ln -s /etc/apache2/sites-available/magentoadmin.conf /etc/apache2/sites-enabled

The file /etc/apache2/sites-enabled/magentoadmin.conf should contains something like this:

<Virtualhost XXX.YYY.ZZZ.TTT:80>
      DocumentRoot /a/path
      <Directory /a/path>
           # your magento configuration here

You should force Magento to load the admin panel when a request is sent to by using the following server variables in this file:

<Virtualhost XXX.YYY.ZZZ.TTT:80>
      DocumentRoot /a/path
      <Directory /a/path>
      # your magento configuration here
      # force loading the admin store
      setEnv MAGE_RUN_CODE admin
      setEnv MAGE_RUN_TYPE store

Don’t forget to check if everything is ok in your apache configuration with the following command:

user@your_web_server:~$ apache2ctl configtest

If the output is ok, restart apache with the following command:

root@your_web_server:~$ apache2ctl restart

Now, Your apache webserver know what to do if it receive a request for

Step 4: Resolve your new Magento administrative panel domain name

The final preparation step is to explain to your desktop or all required back-office users that must be managed by your webserver. If not, your browser can ask but don’t know where going to find the appropriate answer.

4.1 – Check that domain resolution for your future admin webserver is not fine enough

I’ll give you two methods to check if your Magento admin domain name resolution is able to handle your admin configuration domain name yet:

  • by ping command
  • using your browser.
4.1.1: Check your future admin domain name resolution using the ping command

Open a terminal from your computer, and ping your new admin hostname with the following command:

user@your_web_server: ping

If you have an output like this:

ping: unknown host

You have to configure a DNS resolution for your admin.

4.1.2: Check your future admin domain name resolution with your browser

You can also check if your browser is able to resolve it by opening a new window (or tab) and open the URL

If your browser tell you that it cannot resolve it, you’ll have to made the DNS resolution

Screenshot of chrome browser output when domain name resolution is not found

Screenshot of firefox browser output when domain name resolution is not found

4.2 – Set up your domain name resolution for your Magento future administrative panel

it can be done:

  • For you current desktop:
    • In your %windows_folder%/System32/Drivers/etc/hosts file if you are on windows.
    • In your /etc/hosts file if you are on Linux based distribution.
    • For MAC users, my bank loan have been refused, I don’t have MAC 🙂 (but I suppose it’s also in /etc/hosts file).
  • For different users:
    • In your DNS record.

After that, a

user@your_web_server: ping

must answer something like this:

PING (XXX.YYY.ZZZ.TTT) 56(84) bytes of data.
64 bytes from (XXX.YYY.ZZZ.TTT): icmp_seq=1 ttl=64 time=0.024 ms
64 bytes from (XXX.YYY.ZZZ.TTT): icmp_seq=2 ttl=64 time=0.029 ms
64 bytes from (XXX.YYY.ZZZ.TTT): icmp_seq=3 ttl=64 time=0.029 ms
64 bytes from (XXX.YYY.ZZZ.TTT): icmp_seq=4 ttl=64 time=0.029 ms

and opening URL in your favorite browser should display the Magento login form

Now everything is ready!. Let’s go and update our back-office URL

Step 5: Update Magento configuration to set the new back-office URL

So go in your current back-office and open the System > Configuration > General > Web > Unsecure URL tab: replace now in scope default the web unsecure URL by (Don’t forget to add the trailing / add the end of the URL).

Save config

Log out from the back-office

And open the URL. You should set the login form

Secure your back-office URL

Does your back-office is secured now?

It’s a shame but no:

  • Login form is still available from
  • Everyone able to access to will be able to view the Magento login form.

Try it: open your old admin URL you’ll still view the login form :(. The only thing we have done for now is to redirect people which provide valid login credentials to

Add the following rewrite rule in the Apache configuration file of the website virtualhost /etc/apache2/sites-available/magento.conf will redirect each user who try to access to admin from to the admin domain name

<Virtualhost XXX.YYY.ZZZ.TTT:80>
      DocumentRoot /a/path
      # redirect users to admin domain name if they try to access for login from website
      <IfModule mod_rewrite.c>
                RewriteEngine On
                RewriteCond %{HTTP_HOST} [NC]
                # replace customadminpath by your own admin query string
                RewriteCond %{REQUEST_URI} ^.*/customadminpath/.*$
                RewriteRule ^(.*)$ [R=302,L]
      <Directory /a/path>
            # your magento configuration here

After an Apache restart, your login form is only available from

This is not the object of this post, but many things can be done to improve the ACL of your back-office. For example:

Is there an interest to use a custom domain name if you use the default behavior? I mean yes, and quickly.

Is there an interest to use a custom domain name if you already use something different than admin as suffix to access to your back-office? I mean yes. For sure, it’s quite more difficult to find it, but security issues have shown that it’s easily to find these “hidden” back-offices: Security through obscurity is not security. it’s just security for some times.

Patch against the Magento’s SUPEE-6482 issue

Hello everyone,

I know this is the holidays and you have probably only sun in mind, but security issues can’t wait: this morning Magento have published a new patch against SUPEE-6482 issue which include two issues related to APIs and two cross-site scripting risks.

Continue reading “Patch against the Magento’s SUPEE-6482 issue”

A custom Magento patch file to take care of your specificities?

If – as me – you’ve set Magento patchs file webpage as your browser favorites or if you don’t remember the last time you saw a notification in your back-office which does not concern a security issue, this blog post is for you 🙂

A few weeks ago, I warned you compared to the sense of security that can provide the application of security patches Magento : this is not because you have installed Magento patch files that you are secured: if vulnerable files have been overloaded either by a module coming from Magento connect or by custom development, this is this this file which is used by Magento and which needs to be patch.

So it means Continue reading “A custom Magento patch file to take care of your specificities?”

How to solve message “Invalid file format upload attempt” when importing Magento taxes file?

Yesterday I’ve shared with you some Magento import files for VAT rates

Perhaps you have already faced this kind of message “Invalid file format upload attempt” when importing a Magento taxes file? (I hope because if not, I have a serious problem with my search engine optimization for this blog post 🙂 ).

This problem is due to the control made by Magento during taxes file upload Continue reading “How to solve message “Invalid file format upload attempt” when importing Magento taxes file?”

Magento VAT rates import files

Little quiz: what is the VAT rate in Spain ?
You don’t know ? If you made last year a sell on your website to a Spanish, you should read this article.

I’m sure that you (French) users have noticed that since the January, 1st, orders amount placed on apple store have really increased.

This is due to the new VAT law Continue reading “Magento VAT rates import files”

Are there really limitations in Magento?

We frequently hear that Magento doesn’t allow this or that because it’s not built that way, putting us in an awkward situation having no solution to meet our clients’ needs.
Let’s say for a few examples:

– Magento does not support high volumes of attribute’s options
– Magento is slow
– Magento cannot use reddis server prior the community edition 1.8
– Magento does not allow to connect to PostgresSQL db
– Magento does not allow to support more than 1M products
– The pictures displayed in a configurable product sheet are the pictures of the configurable product and not the ones of the simple product itself, that is not possible

I’ve always seen these requests solved by a strange usage of the back-office or in the worst case, by a non answer. This is weird 🙂 We are really very far far away from the communication used in the tenders, where, versus another e-commerce technical solution, we highlight the better native support of Magento to the customer client request 🙂

Every time I hear these common sentences I’m quite a bit in trouble: where are these limitations? Continue reading “Are there really limitations in Magento?”

Installation and configuration of the Magento Mage_Cache_Backend_File in versions prior EE1.13 / CE 1.8

The Latest Magento releases (community edition 1.8 apha and enterprise 1.13) come with a new cache backend, Mage_Cache_Backend_File.

This backend reduces inode usage when saving the cached content.

You are on a prior version but want to use it? No problem, but there are few things to fix before

Continue reading “Installation and configuration of the Magento Mage_Cache_Backend_File in versions prior EE1.13 / CE 1.8”

The Magento Mage_Cache_Backend_File backend gives some holidays for your inodes

Magento allows to customize the way your website manages its cache. This is done by choosing the appropriate cache backend. I’ve provided an example of this update for the full page cache here

By default, your cache will save cached content into files, due to a cache backend existing in both Magento community and enterprise editions, based upon the Zend_Cache_Backend_File, that saves cached content into files

Magento EE 1.13 comes with a new cache storage: Mage_Cache_Backend_File. This backend is an extension of the native cache backend Zend_Cache_File with some improvements regarding performances: Let’s see what is good inside and if we can use it yet

Continue reading “The Magento Mage_Cache_Backend_File backend gives some holidays for your inodes”

Support for cache tags for all cache engines in the Magento enterprise version 1.13

Did you follow the Magento news, you probably heard that Magento Enterprise version 1.13 completely moved the indexer’s logic to the database server.

This for sure leads to a significant increase in your performance.

But are the indexers the only explanation for those better performances? No: there is a few other things involved in this upgrade: one of these is the support of the cache tags for all cache backends.

Continue reading “Support for cache tags for all cache engines in the Magento enterprise version 1.13”