We are using Sitecore 9.0.2 deployed in PaaS as a general recommendation from Sitecore Security Hardening Guide perspective we are supposed to do the below items:

1)Prevent Anonymous Users access to admin folders

2) IIS should not serve requests to .config's

My Thought is these two above mentioned Security hardening things should be done by default on the PaaS for CD since we are using Sitecore ARM Templates and CM's should still allow above two points.

So no further action is required from our side?

  • Can you restate this as a question? Unclear what you are asking. Commented Mar 22, 2019 at 12:17
  • In short question is in Sitecore PAAS how do we prevent Anonymous Users access to admin folders Commented Mar 22, 2019 at 13:23

2 Answers 2


Default Azure PaaS security

If you have correctly deployed Sitecore on Azure PaaS using the ARM templates and associated Sitecore WebDeploy (.scwdp.zip) packages then by default you will have the following security hardening measures already applied:

Access limited via deny anonymous access web.config rules

Access is limited via deny anonymous access web.config rules. For Sitecore 9.1.0 on CD servers, anonymous access is denied to:

  • /App_Config
  • /xsl
  • /sitecore modules/Shell
  • /sitecore modules/debug
  • /sitecore

IIS request filtering

IIS will not serve requests for .configs via default request filtering rules

Custom errors

<customErrors mode="Off"/> so that stack traces are not shown on unhandled exceptions

Non HTTPS requests

There are 3 IIS rewrite rules.

  1. HTTP Root requests (e.g. www.site.com) will be redirected to HTTPS
  2. HTTP /sitecore requests will be redirect to HTTPS
  3. All other HTTP requests will be forbidden

Request Validation

Request Validation is enabled by default.

Contained Database Users

All users are contained with unique usernames and passwords.

Database firewall is enabled

Only Azure IP's can access your database server.

xConnect secured via client certificate authentication and API secrets

This is well-known, but just including here.

Azure Search and Redis require API keys

These are generated and set by the ARM templates.

Other things you should do

Other things you could consider

This is by no means an exhaustive list as security is very open-ended, but hopefully it gives some steps in the right direction.


The Sitecore hardening guide describes this in detail. All tasks can be found here.

An overview of all hardening measured for each role has been documented over there, together with an example whether or not it has been implemented on PaaS or via SIF:


Applies to: All core roles

Sitecore Installation Framework: Administrator password parameter available (SitecoreAdminPassword). In 9.0.2 and earlier, SIF does not enforce changing the administrator password. In 9.1 and later, SIF will generate a random password if you do not change the default value.

Azure Toolkit: Administrator password is changed by default - enforced by ARM template.

Edit: In regards to the comment below: Disable "script" and "execute" permissions

find your handler node in the <system.webServer> section:

<system.webServer> <modules>...</modules> <handlers>...</handler>

and change the handler entry to the following: <handlers accessPolicy="Read, Write">

this is change that the IIS manager makes to the web.config when applying that specific change. Other IIS manager specific changes can made as well. What I did?

I made all the changes and used winmerge as comparison tool to see what changes had been made to the web.config and applied those changes to my Azure deployment.

  • This hardening guide is true for IAAS but if we are deploying in PAAS many of these don't hold true for example : IIS should be configured so that both “Script” and “Execute” permissions & disable upload watcher are some of security hardening activities which are not true for PAAS Commented Mar 25, 2019 at 14:22
  • the hardening guide is for Sitecore general: as you can see, there are Azure Toolkit (ARM based deployments) and SIF deployment remarks over there. Although some mitigations are IIS specific (using IIS manager), they can be applied on every installation, as it makes instance (web.config) specific changes. I updated my answer for that specific remark.
    – Bas Lijten
    Commented Mar 26, 2019 at 9:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.