Skip to content

Headers & allowlists

Beyond filtering malicious requests, managed.dev gives you controls over who can reach a site at all and how browsers are told to treat your responses. These are the access-layer parts of the security pipeline: managed security headers, password protection, IP allowlists, and login lockout. Some are on by default; others you configure per environment.

Every response is served with a hardened baseline of security headers, so you don’t hand-maintain them in .htaccess or theme code:

Header What it does
Strict-Transport-Security (HSTS) Forces HTTPS for future visits, eliminating downgrade and SSL-strip attacks.
Content-Security-Policy (CSP) Constrains which sources can load scripts, styles, and frames, blunting XSS.
X-Content-Type-Options: nosniff Stops browsers from MIME-sniffing responses into executable types.
X-Frame-Options / frame-ancestors Prevents clickjacking by controlling who can frame your pages.
Referrer-Policy Limits how much referrer information leaks to other origins.

The baseline is tuned to be safe for typical WordPress sites. CSP in particular can need site-specific tuning when a theme or plugin loads assets from many origins — the baseline favors compatibility, and you can request a stricter policy.

Any environment can be put behind HTTP password protection — most useful for preview and staging environments you want to share with a client or reviewer but keep off the public web and out of search indexes.

  1. Open the environment in the dashboard and go to its Security (or access) settings.

  2. Enable password protection and set the shared username and password.

  3. Share the credentials with reviewers. Visitors are prompted before any page loads; search engines never see content.

Password protection sits in front of the application, so it gates the whole environment — including wp-admin and the REST API — not just the front end. It’s an environment-level setting, so production can stay public while a preview stays gated. See configuration & secrets for how settings differ per environment.

For environments that should only be reachable from known networks — an internal staging site, an admin-only environment — you can restrict access to an allowlist of IP addresses or CIDR ranges. Requests from any other address are refused at the firewall before reaching your code, and the refusal is recorded as a block.

wp-login.php is the most-attacked URL on any WordPress site. Login lockout watches authentication attempts and temporarily blocks a source after repeated failures, stopping credential-stuffing and brute-force runs without locking out legitimate users for a single typo. Lockouts are attributed to login-lockout in Security → Blocks, so you can see attack volume against your login endpoint at a glance.

Pair lockout with magic-link SSO into wp-admin so your team doesn’t rely on shared passwords at all — the strongest accounts are the ones with no password to brute-force.

Control Who configures it
Security header baseline Platform-managed (custom CSP/HSTS via support)
Password protection Client-settable per environment
IP allowlists Client-settable per environment
Login lockout On by default