Restricting the administration
This page is for system administrators at a host and for support staff who set up a customer's site. The
administration is where content is published, roles are granted and settings are changed; the sign-in
(/user/login, /admin/user/login) is the most attacked address of any site
(Security hardening). The
reference is 13.5 The administration siteaccess.

Contents
- What is there by default
- Its own host name
- Network restrictions
- A browser check in front
- Least privilege
- Configuration from version control
- The setup wizard stays closed
- Checklist
What is there by default
- The administration is a siteaccess of its own (usually
admin). The installer writes[SiteAccessSettings] RequireUserLogin=trueinto itssite.ini.append.php, so every page asks for a sign-in. - Access to each function is decided by roles and policies (
setup/*,content/*,audit/*...). - The sign-in costs the same for an unknown login as for a wrong password, so it does not reveal which accounts exist.
- The audit's alert rules
brute_force(20 failures from one network in 5 minutes) andbrute_force_user(10 for one account in 15 minutes) report attacks (Audit trail).
Its own host name
Give the administration a host name of its own, for example admin.example.com, matched by
[SiteAccessSettings] HostMatchType, rather than a path below the public site. It can then be restricted as a unit:
its own virtual host, its own certificate, its own firewall rule. For hosts this also makes support simpler: the
customer's editors know one address, and the public site's cache and CDN never see administration traffic.
Network restrictions
From the strongest to the simplest, per web server:
| Server | How |
|---|---|
| Apache | on the administration's virtual host, Require ip with the customer's networks, or HTTP basic authentication (AuthType Basic, mod_auth_basic) |
| nginx | allow and deny in the administration's server block |
| Velocity | no HTTP authentication of its own: the firewall, a VPN, a reverse proxy in front, or a separate Velocity bound to an internal address |
<Location />
Require ip 203.0.113.0/24 2001:db8::/48
</Location>Behind a proxy, the address Exponential sees is the proxy's unless TrustedProxies[] is set; a restriction in the
proxy itself avoids that question (TLS and HTTPS).
Note
Customers with editors who travel or work from home may not have a fixed network. A VPN, or the browser check below, then fits better than an address list. Agree it with the customer and write it into the site's documentation.
A browser check in front
request-shield's Exponential examples put a browser check before the sign-in form and the administration, scan every
parameter for attacks, and can limit the administration to a network (EXP-ADMIN-NET). The administration's
background requests (the Admin 4 mega menu) get a machine-readable answer instead of a check page. Choose the main
rules file by layout: exponential-admin-uri.rules for /admin on the same host, exponential-admin-host.rules for an
administration host of its own. See request-shield and request rules.
Least privilege
Give editors the roles they need, not Administrator. Policies that matter for security (13.5):
| Policy | Gives |
|---|---|
setup/setup | settings views and changes |
setup/managecache | cache clearing |
audit/read, audit/manage | the audit trail; archives, settings, "Verify now" |
mailpreferences/administrate, mailpreferences/export | the mail preference system; exports with addresses |
contentfinder/search, contentfinder/delete | finding content by id or path, and removing it from there |
user/login per siteaccess | who may sign in to the administration at all |
One personal account per person, and admin retired as a sign-in
(Account hygiene). The host's own support staff should have
personal accounts too, created and removed with their employment, never a shared "support" login.
Configuration from version control
With [ConfigurationSettings] ManagedByDeployment=enabled on a production administration siteaccess, the
administration cannot run the setup wizard, edit settings or templates, activate extensions or install packages
(Configuration managed by the deployment). Use it where settings and
templates come from Git: a stolen administrator session can then no longer change code or configuration.
The setup wizard stays closed
On an installed site, setup/init only shows "This site is already installed" and writes nothing. Keep:
# settings/override/site.ini.append.php
[SiteAccessSettings]
CheckValidity=false
[SetupSettings]
AllowWizardOnInstalledSite=disabledWhile CheckValidity is true (the shipped default before an installation), every request is sent to the setup
wizard. Never set it back on a live site; the setup wizard on shared hosting
page covers the provisioning side.
Checklist
- To do: The administration on its own host name.
- To do: Restricted by network, VPN, basic authentication or the shield's browser check.
- To do: No shared logins; personal accounts for editors and for the host's support staff;
adminretired. - To do: Roles reviewed:
setup/setup,audit/*,mailpreferences/exportonly where needed. - To do: Two-step sign-in required for administrators (Two-step sign-in).
- To do:
ManagedByDeployment=enabledwhere configuration comes from version control. - To do:
CheckValidity=false,AllowWizardOnInstalledSite=disabled.
Related pages
- Security for hosts: overview
- Chapter 13: The administration siteaccess
- Change the administrator password
- Request rules
- Free documentation: this page is free to copy, translate and improve under the GNU FDL 1.3.
Become an Exponential Partner
Partners share their information, provide funding, contribute back and develop the products with us, and that is how Exponential grows. A partner website and dashboard are planned for mid-2027: please become a partner today to speed up our growth rate and land new features faster.