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.
Managed security headers
Section titled “Managed security headers”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.
Password protection
Section titled “Password protection”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.
-
Open the environment in the dashboard and go to its Security (or access) settings.
-
Enable password protection and set the shared username and password.
-
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.
Firewall IP allowlists
Section titled “Firewall IP allowlists”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.
Login lockout
Section titled “Login lockout”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.
What you set vs what the platform manages
Section titled “What you set vs what the platform manages”| 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 |