---
title: Restrict environment access
slug: dxp/cms12-docs/restrict-environment-access
docTags: 
createdAt: 2026-06-01T17:39:49.387Z
---

:::hint{type="info"}
**Note**
This article pertains to the Optimizely Content Management System (CMS) 11/Optimizely Customized Commerce 13 versions. For CMS 12/Customized Commerce 14, see [this article](docId\:TmmcUz3rmOaZZejjDwj3l).
:::

## Configure restrictions

Customers often want to add security to their solution by restricting access to environments or views; for example, locking down environments such as *Integration* and *Preproduction*, or specific interfaces such as the edit or admin view. Access is limited based on a particular range of IP addresses.

Also, it is common to have different restrictions in different environments, such as *Production* having different settings than *Integration*.

You can create restrictions by blocking a hostname and by adding specific IPs to the allow list for your Web App environment in the `web.config`. You can do this for multiple environments in the same `web.config` by assigning specific rules for each domain, you can use [Environment configuration transforms](docId\:MATFL0bRew1vNbAQAKWcV) to achieve different configurations in different environments.

Only the IPs of the CDN nodes are visible to this feature. You cannot use IP restrictions to restrict access to the environment or views because traffic to the Web Apps flows through the CDN. You can restrict access to the environment or views by using rewrite rules, which provides more flexibility.

### Settings

- `HTTP_HOST` – The hostname of your Web App as entered by the user browsing it, such as `mywebapp.dxcloud.episerver.net` or `www. mydxcsite.com`. The `HTTP_HOST` supports matching by pattern.

:::hint{type="info"}
**Note**
An added pattern must match all enabled hostnames for the site, not just the Web App name, if you want to make sure the rule covers all the URLs.
:::

- `HTTP_True_Client_IP` – The originating IP address of a client connecting to your site through the CDN. Supports matching by pattern.

You can use any server variable or HTTP header when you create these rules. For information about matching the different parts of a URL with these rules, see [Access URL parts from a rewrite rule](http://www.iis.net/learn/extensions/url-rewrite-module/url-rewrite-module-configuration-reference#Accessing_URL_Parts_from_a_Rewrite_Rule) in Microsoft's *URL Rewrite Module Configuration Reference*.

### Example 1: Restrict access to two hosts

The following example restricts access to the two hosts listed (`custom12a3binte.dxcloud.optimizely.net` and `custom12a3bprep.dxcloud.optimizely.net`) to the specified IP (88.250.74.6) if added to the `<system.webServer>` section of `web.config`:

```xml
<rewrite>
  <rules>
    <rule name="Block unauthorized traffic"
          stopProcessing="true">
      <match url=".*" />
      <conditions>
        <add input="{HTTP_HOST}"
             pattern="custom12a3binte\.dxcloud\.optimizely\.net|custom12a3bprep\.dxcloud\.optimizely\.net" />
        <add input="{HTTP_True_Client_IP}" 
             pattern="^88\.250\.74\.6$"
             negate="true"/>
      </conditions>
      <action type="CustomResponse" 
              statusCode="403" 
              statusReason="Forbidden" 
              statusDescription="Site is not accessible" />
    </rule>
  </rules>
 </rewrite>
```

:::hint{type="info"}
**Note**
If you want to make sure that no one can access any of these sites, you need to make sure they have no other host names added to them.
:::

A DXP Service site has one default hostname that is accessible from the Internet; for example:

```javascript
custom12a3bprep.dxcloud.episerver.net
custom12a3bprep-slot.dxcloud.optimizely.net (used during deployments)
```

You also need to add any other domains, such as`www.mydxcsite.com`, if the rule should cover that also. Because patterns are supported, `prep\\.|-slot\\.` would be a valid pattern for the default hostnames `custom12a3bprep.dxcloud.optimizely.net` and `custom12a3bprep-slot.dxcloud.optimizely.net`.

:::hint{type="info"}
**Note**
If the slot-address is blocked, it will prolong the deployment time and prevent manual validation of the slot before go live(s).
:::

### Example 2: Restrict access to hostnames matching patterns

The following example restricts access to hostnames matching the patterns in the first rule (`inte.` and `prep.`) to the specified IP **(88.250.74.6)** and the URL `/episerver` for the hostnames `www.mydxcsite.com` and any hostname that matches the `\*prod.\*` pattern to the specified IP **(88.250.74.6)** if added to the `<system.webServer>` section of `web.config`:

```xml
<rewrite>
  <rules>
    <rule name="Block unauthorized traffic in integration and preproduction"
          stopProcessing="true">
      <match url=".*" />
      <conditions>
        <add input="{HTTP_HOST}" 
             pattern="inte\.|prep\." />
        <add input="{HTTP_True_Client_IP}" 
             pattern="^88\.250\.74\.6$" 
             negate="true"/>
      </conditions>
      <action type="CustomResponse" 
              statusCode="403" 
              statusReason="Forbidden" 
              statusDescription="Site is not accessible" />
        </rule>
        <rule name="Block logins and dashboard in production" 
              stopProcessing="true">
      <match url="login.aspx|episerver" />
      <conditions>
        <add input="{HTTP_HOST}" 
             pattern="www\.mydxcsite\.com|prod\." />
        <add input="{HTTP_True_Client_IP}" 
             pattern="^88\.250\.74\.6$" 
             negate="true"/>
      </conditions>
      <action type="CustomResponse" 
              statusCode="403" 
              statusReason="Forbidden" 
              statusDescription="Site is not accessible" />
    </rule>
  </rules>
</rewrite>
```