Protect a CMS administration area
A detailed guide for WordPress and 1C-Bitrix: compare Direct and Gateway, connect the module, prepare recovery and enable enforcement without locking out administrators.
What the CMS module actually controls
BusinessProxy Admin Gateway is a local access-control layer for a CMS administration area. It checks whether the browser arrived through an approved BusinessProxy launch and blocks protected routes when that authorization is missing. It does not replace the CMS login, change administrator passwords or grant permissions inside the CMS.
Deploy protection gradually. First connect the site and observe real traffic, then prepare recovery, and only after that enable blocking. This order matters because CMS platforms often use administration-looking routes for public forms, AJAX, scheduled jobs and integrations.
Access model
Choose Direct or Gateway
Both methods begin with the same account, workspace policy and MFA checks. The difference starts after authorization: Direct hands the browser over to the verified CMS origin, while Gateway remains in the path of every administrative request.
On the original HTTPS domain
BusinessProxy verifies the user, workspace policy and fresh MFA, then the CMS module creates a bounded local browser session on the verified origin. Page traffic goes directly between the browser and the site.
- The CMS traffic stays between the browser and the site.
- No App Gateway route or Gateway traffic is consumed.
- The CMS plan includes this access method.
Through a controlled BusinessProxy route
The browser opens an Alias address and BusinessProxy remains in the path of every CMS request. Gateway relays traffic to a public origin or through Connector to a site that is not exposed to the internet.
- A managed or custom Alias is used as the CMS address.
- A route can be stopped centrally without changing Direct.
- The route uses App Gateway capacity and traffic.
More control because BusinessProxy stays in the traffic path.
Gateway is useful when opening the door is not enough. It gives the team a controlled CMS address, reaches private origins and lets the browser apply visible protection to a named user session.
Connector initiates the connection from the site network. The CMS does not need an inbound public address.
BusinessProxy can reject new requests and revoke the Gateway session without waiting for a new Direct launch.
With the browser extension and app policy enabled, pages can show a user watermark and deter copy, print, save and known screenshot actions.
A managed Alias works immediately; a custom domain can be attached when the selected App Gateway plan supports it.
Alias is the technical address of a Gateway route, not a separate product. The managed Alias is not billed on its own: Gateway billing covers the route and processed traffic. Watermarks and screenshot deterrence require the BusinessProxy browser extension and are best-effort controls, not endpoint DLP.
Safe rollout
One rollout sequence for every CMS
Platform screens and route names differ, but the security sequence remains the same. Complete it once for every connected site, including staging and canary sites.
Prepare an independent recovery route
Keep an active CMS administrator account and server or hosting access before changing protection. Generate recovery codes in the module and store them outside the CMS. Recovery must not depend on the same BusinessProxy session you are about to test.
Connect the site without enabling blocking
Install the current signed package, leave the module in Monitor mode and complete the explicit site confirmation in the intended workspace. Connection creates a stable Site ID and pairs purpose-specific audit and revocation secrets.
Resolve every readiness warning
Readiness is a set of independent checks, not a single connection flag. Confirm the site binding, JWKS, signing support, paired secrets, protected paths, audit delivery and recovery. A prepared recovery-code set does not enable emergency access by itself.
Observe real traffic in Monitor mode
Open the admin area through BusinessProxy, then open it directly. The first route must create allowed audit events; the second must create monitor-deny events without locking you out. Exercise updates, background jobs, AJAX and public forms before proceeding.
Enable enforcement and test revocation
Switch to Enforce only after a successful recovery test. Launch a new managed session, sign in to the CMS, revoke that session in BusinessProxy and confirm that the next protected request is denied. Finally, verify one unused recovery code.
Platform instructions
Install and configure your CMS module
Follow the chapter for the installed platform. Do not copy route settings from another CMS: protected surfaces and early bootstrap points are platform-specific.
WordPress
StableProtect wp-login, wp-admin, XML-RPC and selected authenticated REST traffic. Direct and Gateway access are supported.
/wp-login.php/wp-admin/*/xmlrpc.php/wp-json/*Install the plugin and early loader
Download the current WordPress package from BusinessProxy Downloads. In WordPress open Plugins, upload the ZIP, activate BusinessProxy Admin Gateway and then open Settings → BusinessProxy Gateway.
Install the optional must-use loader from the settings page after the first Monitor check. It starts protection before ordinary themes and plugins. If the host blocks file writes, place the supplied loader in wp-content/mu-plugins manually.
wp-content/plugins/businessproxy-admin-gateway/ wp-content/mu-plugins/businessproxy-admin-gateway-loader.phpConnect the correct site and workspace
In Connection enter the BusinessProxy account email and choose Public DNS origin or Internal via Connector. Open the confirmation link, sign in to the intended workspace and approve this exact site. Return to WordPress and refresh the connection status.
New installations generate separate audit and revocation secrets during confirmed pairing. Do not paste shared secrets into the database. Server constants remain optional compatibility overrides.
Prepare recovery and complete readiness
Generate recovery codes, save the displayed values immediately and run the recovery test from the BusinessProxy CMS site page. The codes are displayed once; only hashes remain in WordPress. Refresh JWKS and confirm that connection, pairing, Direct capability and audit checks are ready.
Validate Monitor, then enable Enforce
Keep Monitor active while testing wp-login, wp-admin, media upload, plugin and core updates, cron and admin-ajax. A managed launch must produce allow events. A direct unapproved request must produce monitor-deny but continue to load.
After the checks pass, enable Enforce. Open the site from the BusinessProxy portal or compatible extension, complete the normal WordPress login and test session revocation. BusinessProxy authorizes access to WordPress; it does not replace the WordPress account login.
1C-Bitrix
StableProtect the Bitrix administration area and selectively cover REST, tools and services routes after checking public integrations.
/bitrix/admin/*/bitrix/tools/*/bitrix/services/*/rest/*Install the Bitrix module
Download the signed BusinessProxy Bitrix archive and verify its checksum in Downloads. Extract the module so its final path is /local/modules/businessproxy.admingateway/. In the Bitrix administration panel open Marketplace → Installed solutions and install BusinessProxy Admin Gateway.
Open the module settings and leave Monitor mode selected. Do not add the strict loader and do not enable Enforce during initial connection.
/local/modules/businessproxy.admingateway/Choose a public or internal origin
On the Connection tab enter the BusinessProxy email. Choose Public site for an externally reachable HTTPS domain. Choose Internal site via Connector when Bitrix is reachable only inside a local network, Docker, Kubernetes or VPN.
For an internal site, enter the upstream address exactly as the Connector can reach it, not the address from the administrator browser. Confirm the connection in the intended workspace, return to Bitrix and refresh the status.
Public: https://admin.example.com/ Internal: http://bitrix:80/ Internal: http://intranet-bitrix.local/Refresh JWKS and inspect every readiness check
On Status refresh the connection and JWKS. A confirmed connection provides the stable Site ID and pairs separate audit and revocation secrets. If the page says that a secret is required, complete Reconnect in the same workspace instead of entering a raw value in Bitrix.
The readiness result is strict. Recovery codes satisfy the recovery-material part, but the separate Allow emergency access switch must also be enabled. Disabled /bitrix/tools or /bitrix/services protection remains visible as an unresolved check.
Choose protected Bitrix routes deliberately
Protect /bitrix/admin as the primary administration surface. Review /rest before enabling it because integrations may use this route. The /bitrix/tools and /bitrix/services trees can host public CAPTCHA, component AJAX and service handlers, so they are off by default.
Enable tools and services protection only after identifying public handlers and moving them to explicit allowed routes where needed. A green badge is not worth breaking checkout, forms or background integrations.
Generate recovery codes and test Monitor
Enable emergency access, generate a recovery-code set and store the displayed values outside Bitrix. A legacy server secret is not required when unused codes exist. Use one code in a controlled recovery test before enabling blocking.
While Monitor is active, test the administration area through BusinessProxy and directly. Also test updates, file upload, agents, cron, public forms, CAPTCHA and application-specific AJAX. Review allow and monitor-deny events in Audit.
Enable Enforce and only then consider the strict loader
After recovery and Monitor checks pass, enable Enforce and start a new Direct or Gateway session from BusinessProxy. Complete the normal Bitrix login, revoke the BusinessProxy session and confirm that the next protected request returns the branded denial page.
The optional strict loader moves the first check earlier in Bitrix bootstrap. Add it only after stable Enforce operation. Keep server or hosting access available so the include can be removed without entering the Bitrix administration area.
Readiness
How to read “Not ready”
“Not ready” does not always mean that connection failed. It means at least one required local check is unresolved. Read the named checks and fix them independently instead of reconnecting the site repeatedly.
Reconnect without losing the domain
Move a custom Alias to the current CMS connection
A CMS reinstall, duplicate plugin cleanup or a new Site ID can leave the verified hostname attached to an older connection. Do not repair this state by deleting the domain and creating it again. The built-in transfer keeps the verified domain and certificate while moving only its CMS route.
Prepare the current CMS connection
Do not reset the old connection yet. Install the current signed module on the live site, complete pairing in the same workspace and run CMS verification. Enable Gateway for the new connection before the transfer so BusinessProxy has a prepared target route.
The target connection must be active and available to the same workspace owner or administrator. Direct readiness is independent and does not have to be disabled for the transfer.
Transfer the existing Alias
Open the old CMS connection, find BusinessProxy Gateway and choose Transfer custom domain. Select the existing Alias hostname and the prepared current CMS connection, review both sites and confirm the operation.
BusinessProxy changes the binding in one operation. The Alias ID, DNS ownership proof, certificate and recorded history remain in place. Active Alias sessions and unfinished launches for the old connection are revoked so they cannot continue against the new route.
Verify the new route
Open the current CMS connection and confirm that the transferred hostname is selected in Alias used for launch. Choose Gateway as the saved browser mode when users should open this managed hostname. If Direct is selected, BusinessProxy will continue to open the canonical HTTPS domain of the CMS instead.
Perform one real launch, sign in to the CMS, open a protected page and revoke the session. A new launch must use the transferred hostname; the revoked session must be denied on its next protected request.
Retire the stale connection
Remove or offboard the old CMS connection only after the current connection passes site verification and the Alias launch succeeds. Do not delete the verified custom domain: it now belongs to the current CMS route.
Troubleshooting
Resolve the visible symptom first
Preserve the Site ID and local recovery material while diagnosing. Reset or reinstall only when the instructions for the exact error require it.
Buttons report that the CMS administrator session expired
Reload the settings page and sign in again. On self-hosted Bitrix, also verify that PHP session.save_path is persistent and writable by the PHP worker; changing PHPSESSID between GET and POST invalidates the Bitrix sessid.
A secret is required after connection
Do not invent or paste a shared value. Refresh the connection, then run Reconnect in the same workspace so the module can repeat purpose-bound pairing.
Direct returns CMS_DIRECT_HTTPS_REQUIRED
Direct requires the verified canonical site to use public HTTPS. Configure TLS and correct origin detection, or use Gateway with Connector for an internal or HTTP-only site.
The site became inaccessible after Enforce
Use an unused recovery code from the protected page. If the CMS cannot render that page, use server or hosting access to disable the early loader or set the module to Off. Do not delete the module directory before restoring a known access path.
Related guides