WordPress REST API Blocked by a Security Plugin: Allow Safely, Not Blindly

What the WordPress REST API really does (and why blocks hurt)

The WordPress REST API lives under /wp-json/. It’s not just “an API for developers.” It’s part of how modern WordPress works.
Gutenberg, the block editor, relies on it. Many plugins rely on it. Some themes rely on it. Headless setups rely on it like lungs rely on oxygen.

Security plugins often treat /wp-json/ as an “attack surface” because, frankly, it is one.
REST endpoints can expose data, accept writes, and trigger expensive queries.
The right security posture isn’t “block it all” or “allow it all.” It’s “make sure access matches intent.”

What “blocked” usually means

When someone says the REST API is blocked, they often mean one of these:

• 403 Forbidden: a WAF rule, security plugin, ModSecurity, reverse proxy ACL, or CDN is refusing the request.
• 401 Unauthorized: REST endpoint requires authentication; your client isn’t presenting valid credentials (or cookies are being stripped).
• 404 Not Found: rewrite rules, routing, or server config is preventing WordPress from receiving the request.
• 5xx: the request reaches WordPress, but triggers a fatal error, timeout, or resource limit.
• 200 but wrong body: you’re getting HTML (login page, block page) instead of JSON—classic “it’s blocked but politely.”

Good operations starts with classification. If you can’t say where the block occurs—edge/CDN, WAF/plugin, web server, PHP, or WordPress—you’re just guessing with confidence.
That’s not engineering; that’s gambling in a hoodie.

Interesting facts and history that explain today’s failures

A few context points help you predict what breaks and why security tooling gets jumpy around /wp-json/.

1. The REST API started as a feature plugin. It wasn’t always core; it matured before being merged into WordPress itself.
2. WordPress 4.7 brought the REST API into core. That’s when “REST API issues” went from niche to mainstream because more sites suddenly depended on it.
3. Gutenberg increased REST API call volume. Editing a post became a chatty client-server conversation; firewalls that “allowed a few requests” now saw dozens.
4. XML-RPC was the earlier remote interface. Many security tools learned to fear remote publishing surfaces from years of XML-RPC brute force and pingback abuse—REST inherited suspicion.
5. Some endpoints are public by design. For example, discovery endpoints and many read operations are intentionally accessible; blocking them breaks legitimate behavior.
6. WordPress has a built-in “REST API authentication cookie” model. It works fine in browsers, but headless apps and server-to-server clients often need application passwords or OAuth-like patterns.
7. Security plugins often pattern-match requests. They’re not running a PhD thesis on your intent; they’re matching heuristics: unusual User-Agents, bursty traffic, JSON payloads, and keywords.
8. Many WAF rules were written for generic PHP apps. WordPress REST routes can look like “path traversal” or “scanner behavior” to rules designed for other apps.
9. Caching layers can lie. A cached block page served as 200 is still a block; it just wastes more of your time first.

A useful mental model: security tooling isn’t malicious; it’s just aggressively literal.
Your job is to give it a narrowly-scoped exception it can understand, and logs that prove it’s working.

Fast diagnosis playbook (check first/second/third)

If you’re on-call, you don’t have time for philosophy. Here’s the “find the bottleneck fast” sequence that works in real environments.

First: identify where the response is generated

• Does the response include CDN/WAF headers? If yes, start at the edge.
• Do you see your web server headers (nginx/Apache) and a normal JSON body? If yes, it’s WordPress/app-level.
• Do you see HTML with a block page? If yes, it’s almost always edge/WAF/plugin.

Second: compare unauthenticated vs authenticated requests

• Unauthenticated request to /wp-json/ should typically return JSON (site index) with 200.
• Authenticated requests should return data; if they fail, focus on cookies, nonces, application passwords, or blocked headers.

Third: confirm whether blocks are rule-based, rate-based, or reputation-based

• Rule-based: consistent 403 for a specific path/payload.
• Rate-based: works for a few requests then fails; often returns 429/403.
• Reputation-based: works from your laptop but fails from CI/CD, a cloud region, or a partner IP range.

Fourth: validate WordPress is actually receiving requests

• Check access logs and correlate with request IDs or timestamps.
• No access log entry? The block happened upstream.

Paraphrased idea (attributed): Werner Vogels is associated with the notion that “everything fails, all the time,” so you design and debug with that expectation.
That mindset is the whole trick here: assume blocks are layered and intermittent until proven otherwise.

Know the enemy: where REST API blocks actually occur

Layer 0: DNS and the wrong host

You’d be amazed how often “REST API blocked” is actually “the client is calling a different hostname that points to a different stack.”
Especially in corporate setups where marketing has three domains, two CDNs, and a staging site that escaped into production.

Layer 1: CDN / edge WAF

Cloud WAFs are great at blocking scanners and also great at blocking your own apps if your patterns look scanner-ish.
WordPress REST endpoints often trip “API abuse” or “PHP exploit” signatures because the URL contains predictable nouns and the traffic is bursty.

Layer 2: reverse proxy rules

Nginx/Apache rules intended to protect xmlrpc.php sometimes accidentally match wp-json.
Or someone copied a snippet that blocks “anything not a page view” because they were fighting bots at 2am.
They won. You lost.

Layer 3: ModSecurity / CRS

The OWASP Core Rule Set can flag JSON payloads, certain parameter names, or encoded characters.
If you see ModSecurity in logs, treat it like a separate system with its own policy, not as “part of Apache.”

Layer 4: WordPress security plugin

Plugins like Wordfence, iThemes Security, Sucuri (plugin side), etc. can block via:

• Country blocks
• Rate limits
• “Block suspicious URLs” heuristics
• Blocking “unknown user agents”
• Blocking specific endpoints or query patterns

The pain is that plugins often return a generic 403 page, which looks identical to several other layers.
You need logs to know whether the plugin did it.

Layer 5: WordPress authentication and capabilities

Not all “blocked” is security plugin drama. Sometimes the REST API is working, but your client is not authorized.
That’s a feature. The bug is your assumption.

Layer 6: PHP crashes and resource limits

A REST request can be heavier than a normal page view because it may hit custom queries, load more plugins, and bypass caches.
If a security plugin increases CPU cost (some do), the API becomes the canary.

Practical tasks: commands, outputs, and decisions (12+)

These tasks are written for a typical Linux VM hosting WordPress behind nginx or Apache, possibly with a CDN.
Adapt paths to your distro. The point is the method: measure, classify, then change one thing at a time.

Task 1: Fetch the REST index and inspect headers

cr0x@server:~$ curl -sS -D - -o /dev/null https://example.com/wp-json/
HTTP/2 403
date: Sat, 27 Dec 2025 10:12:11 GMT
content-type: text/html; charset=UTF-8
server: cloudflare
cf-ray: 88c0c0d00abc1234-LHR

What it means: The block is at the edge (Cloudflare shown by headers), not WordPress.
Decision: Stop changing WordPress settings. Go to CDN/WAF logs and rules first.

Task 2: Compare with origin (bypass CDN) to isolate the layer

cr0x@server:~$ curl -sS -D - -o /dev/null --resolve example.com:443:203.0.113.10 https://example.com/wp-json/
HTTP/2 200
date: Sat, 27 Dec 2025 10:12:20 GMT
content-type: application/json; charset=UTF-8
server: nginx

What it means: Origin serves REST correctly; CDN blocks it.
Decision: Implement a scoped WAF allow rule for /wp-json/ or specific routes, not a global bypass.

Task 3: Confirm whether WordPress is even receiving blocked requests

cr0x@server:~$ sudo tail -n 20 /var/log/nginx/access.log
203.0.113.50 - - [27/Dec/2025:10:12:20 +0000] "GET /wp-json/ HTTP/2.0" 200 2456 "-" "curl/8.5.0"

What it means: You see only the bypassed request (200). The blocked request never hit nginx.
Decision: Ignore PHP/WordPress logs for the 403 case; it’s upstream.

Task 4: If you suspect a WordPress security plugin, check plugin logs for blocks

cr0x@server:~$ sudo grep -R "wp-json" -n /var/www/html/wp-content/wflogs 2>/dev/null | head
/var/www/html/wp-content/wflogs/attack-data.php:112:... "uri":"/wp-json/wp/v2/users", "action":"blocked" ...

What it means: Wordfence-style logs show the URI and action.
Decision: Tune the plugin rule that triggered, or create an allowlist for specific endpoints and actors.

Task 5: Prove what your client is requesting (routes matter)

cr0x@server:~$ curl -sS -i https://example.com/wp-json/wp/v2/posts?per_page=1 | sed -n '1,15p'
HTTP/2 200
content-type: application/json; charset=UTF-8
x-wp-total: 125
x-wp-totalpages: 125

What it means: Basic read routes are fine.
Decision: If only certain routes fail (often /users, /media, custom plugin routes), scope your allow rules to those routes.

Task 6: Check whether the response is JSON or a “nice” HTML block page

cr0x@server:~$ curl -sS -i https://example.com/wp-json/wp/v2/users | sed -n '1,25p'
HTTP/2 403
content-type: text/html; charset=UTF-8

<html><head><title>Access denied</title>...

What it means: That’s not WordPress JSON; that’s a block page.
Decision: Don’t chase WP permissions yet. Identify which layer renders the HTML.

Task 7: Validate WordPress rewrite rules aren’t broken (404 masquerading as “blocked”)

cr0x@server:~$ curl -sS -o /dev/null -D - https://example.com/index.php?rest_route=/ | head -n 10
HTTP/2 200
content-type: application/json; charset=UTF-8

What it means: Even if pretty permalinks are broken, REST can still work via rest_route.
Decision: If /wp-json/ is failing but rest_route works, you have a rewrite/proxy path issue, not a security block.

Task 8: Check ModSecurity audit log for REST-related rule hits

cr0x@server:~$ sudo grep -R "wp-json" -n /var/log/modsec_audit.log | tail -n 3
--9c7d3a1f-H--
Message: Access denied with code 403 (phase 2). Matched phrase "wp-json" at REQUEST_URI.
Action: Intercepted (rule id: 949110)

What it means: A specific CRS rule is firing.
Decision: Don’t disable ModSecurity globally. Exclude the rule for the specific location or route, and document it.

Task 9: Confirm rate limiting vs consistent blocking (burst test)

cr0x@server:~$ for i in $(seq 1 20); do curl -sS -o /dev/null -w "%{http_code}\n" https://example.com/wp-json/; done | sort | uniq -c
     15 200
      5 429

What it means: You’re being rate limited (429). Often security plugins or CDNs do this.
Decision: Raise thresholds for trusted actors, add caching for safe endpoints, or slow the client. Don’t “allow all.”

Task 10: Inspect nginx/Apache config for accidental blocks

cr0x@server:~$ sudo nginx -T 2>/dev/null | grep -n "wp-json\|rest_route\|deny\|return 403" | head -n 20
1321:    location ~* /(xmlrpc\.php|wp-json) { return 403; }

What it means: Someone blocked wp-json at the web server level (often copied from an “anti-bot” snippet).
Decision: Remove wp-json from that block, or replace it with a tighter rule (e.g., allow index/read routes, restrict writes).

Task 11: Check WordPress itself isn’t configured to disable the REST API

cr0x@server:~$ wp --path=/var/www/html plugin list --status=active
+-----------------------+--------+-----------+---------+
| name                  | status | update    | version |
+-----------------------+--------+-----------+---------+
| disable-json-api      | active | available | 1.3.0   |
| wordfence             | active | none      | 7.11.0  |
| classic-editor        | active | none      | 1.6.3   |
+-----------------------+--------+-----------+---------+

What it means: A plugin explicitly disables JSON/REST functionality.
Decision: Decide whether that plugin still matches your architecture. If you need REST for Gutenberg/headless, it’s incompatible by design.

Task 12: Verify application-level auth works (Application Passwords)

cr0x@server:~$ curl -sS -u "api-user:abcd efgh ijkl mnop" -o /dev/null -D - https://example.com/wp-json/wp/v2/users/me | head -n 12
HTTP/2 200
content-type: application/json; charset=UTF-8

What it means: Auth is valid and not being stripped by a proxy/WAF.
Decision: If this fails with 401/403, check whether Basic Auth is blocked upstream, or whether the user lacks capability.

Task 13: Prove that cookies/nonces are not being mangled by the edge

cr0x@server:~$ curl -sS -I https://example.com/wp-json/ | grep -i "set-cookie\|cache-control\|vary"
cache-control: no-cache, must-revalidate, max-age=0
vary: Accept-Encoding

What it means: REST index shouldn’t be aggressively cached with cookies. If you see surprising cookie behavior, you may have a plugin injecting cookies everywhere.
Decision: Fix cookie injection and caching policies; otherwise CDNs can cache “blocked” experiences.

Task 14: Correlate timing with PHP-FPM or backend saturation (when it’s “blocked” but actually slow)

cr0x@server:~$ sudo tail -n 20 /var/log/php8.2-fpm.log
[27-Dec-2025 10:12:44] WARNING: [pool www] server reached pm.max_children setting (20), consider raising it

What it means: Requests are queueing; a WAF might start timing out and returning synthetic 403/524-like errors depending on provider.
Decision: Fix capacity and slow queries first; otherwise you’ll “allow” the REST API and still be down.

Task 15: Check whether your REST routes are being cached incorrectly (cache poisoning vibes)

cr0x@server:~$ curl -sS -I https://example.com/wp-json/wp/v2/posts?per_page=1 | egrep -i "cache|age|cf-cache-status|x-cache|via"
cf-cache-status: HIT
age: 1800

What it means: A REST response is cached at the edge. That can be fine for public reads, terrible for personalized routes.
Decision: Cache only safe, public, unauthenticated GET routes; bypass caching for authenticated or write routes.

Joke #1: Security plugins are like airport security—mostly fine until you’re the one with a laptop and a belt buckle. Then it’s suddenly personal.

Allow safely: patterns that don’t ruin your weekend

Rule #1: Don’t “enable the REST API.” It’s already enabled. Decide who can do what.

The REST API is not a single switch. It’s a routing framework with endpoints, methods, and permissions.
The safe path is to allow required endpoints and methods, for specific actors, with logging and rate limits.

Start with an inventory: what calls your API?

Before changing rules, list the callers:

• Gutenberg editor in wp-admin (browser clients, cookie auth, nonces)
• Mobile apps (often use application passwords or OAuth flows)
• Headless frontend (server-to-server or browser-to-server, sometimes both)
• Partner integrations (Zapier-like systems, marketing automation, CRM)
• Internal cron/worker jobs (importers, sync tools)

Each of these has different authentication and rate patterns. If you treat them as one blob, your WAF will treat them as one blob too.
And it will block the blob.

Pattern A: Allow public read routes, protect everything else

Many sites only need unauthenticated GET access to public content endpoints (posts, pages, categories, media metadata).
In that scenario:

• Allow GET on known public routes (e.g., /wp-json/wp/v2/posts)
• Block or challenge non-GET methods from anonymous clients
• Keep authentication-required routes available, but behind proper auth

This aligns with least privilege and reduces “API abuse” signatures because you’re not allowing the full method surface to random traffic.

Pattern B: Allow the REST index, but not enumeration endpoints

The REST index (/wp-json/) is frequently used by clients to discover namespaces.
Blocking it can break Gutenberg and plugin UIs. But you can still restrict sensitive endpoints:

• Allow /wp-json/ and /wp-json/wp/v2 to return index metadata
• Harden endpoints that leak data (e.g., user enumeration) by permissions and/or WAF rules

Note: modern WordPress restricts many user endpoints to authenticated users. Your security plugin may be overcorrecting.
Don’t “fix” that by opening user endpoints publicly.

Pattern C: For headless apps, use application passwords and dedicated users

Application Passwords are practical for server-to-server calls. The safe version looks like:

• Create a dedicated WordPress user for the integration
• Grant the minimum role/capabilities needed
• Issue an application password, rotate it, and store it in a secret manager
• Allowlist the integration’s IPs at the WAF if feasible (but don’t rely on it alone)

Avoid using an admin account “because it worked.” It always works. That’s the problem.

Pattern D: Use selective WAF exceptions, not global bypasses

A good WAF exception has:

• A specific path or route match (not a wildcard on /*)
• A method restriction (GET-only, or allow POST only for a route you own)
• An actor constraint (IP, mTLS, header token, or at least a known User-Agent if you’re desperate)
• A time-bound change window for emergencies (then make it permanent properly)
• Logging for “was this exception used”

If your tool only supports “skip all security for this URL,” you can still scope it to one endpoint and then compensate with rate limiting and auth.

Pattern E: Treat write routes as production changes

Allowing POST, PUT, PATCH, DELETE to REST endpoints is not a “make the app work” change.
It’s giving remote clients the ability to modify state. That deserves:

• Change management (yes, even if you’re “agile”)
• Audit logs (who changed what via API)
• Rate limits and abuse detection
• Backups and rollback paths

Pattern F: Cache only what’s safe to cache

REST endpoints are sometimes great cache candidates (public content), and sometimes a disaster (anything user-specific).
At the edge:

• Cache GET requests without Authorization headers and without cookies
• Bypass cache if Authorization exists
• Bypass cache for /wp-json/wp/v2/users/me, admin-like endpoints, and custom authenticated routes

If a security plugin blocks an API call and the CDN caches that block response, you’ve invented a denial-of-service machine that runs on autopilot.
That’s not hypothetical; it happens.

What to avoid, aggressively

• Disabling the security plugin as a “test” and forgetting to re-enable it.
• Allowing /wp-json/ globally at the WAF without method restrictions.
• Allowing Basic Auth everywhere without TLS termination clarity and brute force controls.
• Using an admin API user for integrations.
• Ignoring logs and tuning by superstition.

Joke #2: “Temporary allow-all” is the operational version of “I’ll just hold this glass of water over the keyboard.” It’s fine until it isn’t.

Three corporate mini-stories from the trenches

Incident caused by a wrong assumption: “403 means WordPress permissions”

A mid-size company rolled out a headless marketing site. The frontend lived on a modern framework; WordPress was the content backend.
They tested in staging, everything worked, and then production started throwing 403s on /wp-json/wp/v2/posts.
The engineering team assumed it was a WordPress role issue because the REST API is “WordPress stuff.” Reasonable, and wrong.

They spent hours adjusting roles, adding plugins, and even temporarily granting administrator permissions to the API user.
The 403 persisted. They then “fixed” it by allowing all traffic to /wp-json/ in the security plugin, which seemed to work for a day.
The next morning, their WAF dashboard showed a spike of blocked requests across unrelated endpoints and a wave of automated probes.

The root cause was upstream: the CDN WAF had a managed rule that interpreted the REST route patterns as an API scanner.
Staging was on a different plan with fewer managed rules. Production got the full “enterprise protection” pack.
The security plugin change was irrelevant; it merely changed timing enough to confuse everyone.

The fix was boring and precise: add a WAF exception for GET requests to /wp-json/wp/v2/posts and /wp-json/, keep everything else protected,
and add a rate limit. They also added a synthetic check in monitoring that alerts on non-200 responses for key REST routes.
The incident ended when they stopped assuming the app was at fault and proved where the 403 was generated.

Optimization that backfired: caching the REST API “to reduce origin load”

Another organization had WordPress under heavy traffic. Someone had the bright idea to “cache the REST API at the CDN” because the frontend was making lots of calls.
For public post lists, this was actually a good idea. For authenticated endpoints, it was a slow-motion disaster.

They implemented a broad caching rule for /wp-json/* and saw origin CPU drop. Everyone applauded.
Then editors started reporting that Gutenberg couldn’t save drafts consistently and that user-specific data looked wrong.
Some API responses were stale; some returned HTML login pages cached as if they were JSON; some appeared as 403s cached for minutes.

Security tooling escalated. The security plugin saw repeated “invalid nonce” patterns (because the client was receiving cached responses that didn’t match its session)
and started blocking requests. Now the CDN was caching the block pages too.
The system was “optimized” into a self-reinforcing failure loop: cache wrong thing → client retries → WAF blocks → cache the block → more retries.

The rollback was immediate: stop caching authenticated routes and bypass cache on requests with Authorization or cookies.
They kept caching for a short allowlist of public GET routes with explicit TTLs.
Load went back up a bit, but the platform became stable again—because correctness is the best performance optimization you’ll ever ship.

Boring but correct practice that saved the day: change logs + request correlation

The third team was not flashy. They ran WordPress for a business unit that never wanted surprises.
They had an ops habit: every WAF rule change required a ticket, a short description, and a link to a log sample showing why it was needed.
They also injected a request ID header at the edge and logged it at the origin.

One afternoon, REST calls started failing only for one partner integration. Their monitoring caught a spike in 403s for a custom namespace route.
Instead of guessing, they searched logs by request ID and saw the response was generated at the edge, not by WordPress.
They pulled the WAF change log and found a managed rule update that started treating the partner’s JSON payload as suspicious.

Because they had correlation IDs, they could send the exact failing request sample (minus sensitive fields) to the security team and get a scoped exception approved quickly.
No one disabled the firewall. No one “temporarily allowed everything.” No one argued in Slack for three hours.
The fix was deployed, verified, and written down.

The lesson is unsexy: logs and discipline beat heroics. When you can prove where the block is, you can fix it with a scalpel instead of a chainsaw.

Common mistakes: symptom → root cause → fix

1) Symptom: /wp-json/ returns 403 with an HTML page

Root cause: Edge WAF or security plugin block page is being served, sometimes cached.

Fix: Identify the layer via headers; bypass CDN to origin to confirm; create a scoped allow rule for /wp-json/ index and required routes.

2) Symptom: Works from your laptop, fails from CI/CD or a server

Root cause: IP reputation, geo-block, or different User-Agent triggers security heuristics.

Fix: Use application passwords; allowlist CI IP ranges if stable; reduce request rate; set a legitimate User-Agent; avoid “curl default” in production clients.

3) Symptom: Gutenberg editor shows “The response is not a valid JSON response”

Root cause: REST response is being replaced by HTML (login page, WAF block, PHP warning), or caching is serving non-JSON bodies.

Fix: Fetch failing endpoint with curl -i and inspect content-type/body; fix upstream block; fix PHP warnings; ensure REST routes aren’t cached with HTML bodies.

4) Symptom: 401 Unauthorized on endpoints that “should be public”

Root cause: A plugin or custom code changed REST authentication requirements, or your client is hitting a route that requires auth (like users/me).

Fix: Test the REST index and a public posts route; verify route-level permissions; remove/adjust “disable REST” plugins; use proper auth for protected routes.

5) Symptom: Works for a few requests, then 429/403

Root cause: Rate limiting in a security plugin or edge WAF; sometimes triggered by Gutenberg’s bursty behavior.

Fix: Increase thresholds for authenticated/editor traffic; add route-level caching for public reads; tune client retry behavior; avoid retry storms.

6) Symptom: REST works at origin but fails through CDN

Root cause: Managed WAF rules or bot protection at the CDN.

Fix: Add an exception for necessary routes/methods; bypass bot challenges for authenticated admin/editor paths; keep protection on write routes.

7) Symptom: 404 on /wp-json/ but rest_route works

Root cause: Rewrite rules or proxy config not forwarding the path correctly.

Fix: Fix nginx/Apache rewrite rules; ensure WordPress permalinks are set; check for location blocks that intercept /wp-json.

8) Symptom: Random 5xx on REST endpoints, especially custom ones

Root cause: PHP-FPM saturation, slow DB queries, plugin fatal errors, or security plugin overhead under load.

Fix: Check PHP-FPM logs for max_children; review slow query logs; profile plugin endpoints; implement caching and/or increase capacity carefully.

Checklists / step-by-step plan

Step-by-step: restore functionality without punching a hole in your perimeter

1. Capture a failing request sample. Save method, URL, headers, response code, and body snippet.
2. Classify the failure code. 401 vs 403 vs 404 vs 5xx dictates the next move.
3. Check response headers for origin vs edge. If you see CDN/WAF headers, start there.
4. Bypass CDN to test origin. Use curl --resolve from a trusted host.
5. Confirm whether WordPress logs the request. If no access log entry, the block is upstream.
6. Identify the exact endpoint(s) needed. Don’t “fix wp-json”; fix the specific routes your app uses.
7. Decide public vs authenticated access. Public read routes can be allowed and cached; write/auth routes must be protected.
8. Implement a scoped allow rule. Path + method + actor constraints where possible.
9. Add rate limits for REST routes. Especially for anonymous traffic.
10. Verify with a burst test. Confirm no 429/403 under expected usage.
11. Audit caching behavior. Ensure authenticated requests aren’t cached; ensure block pages aren’t cached as 200.
12. Document the change. Record what was allowed, why, and how to roll back.
13. Add monitoring. Synthetic checks on key REST endpoints, plus alerting on spikes in 401/403/429/5xx.

Production readiness checklist for REST API allowances

• Dedicated API user(s) with minimum privileges
• Credentials stored in a secret manager and rotated
• WAF exceptions scoped to exact routes and methods
• Rate limits on anonymous REST traffic
• Cache policy: public GET only, bypass on Authorization/cookies
• Logging: edge + origin correlation, plus plugin logs if used
• Runbook: how to identify which layer is blocking
• Monitoring: REST health checks and error rate alerts

FAQ

1) Should I disable the security plugin to confirm it’s the problem?

Only if you can do it safely and briefly (maintenance window, restricted access), and only after you’ve checked headers/logs to see whether the block is upstream.
In many real setups, the CDN/WAF is blocking before WordPress ever sees the request—disabling a plugin won’t prove anything.

2) Is it safe to allow /wp-json/?

Allowing the REST index and specific public GET routes is usually safe and often necessary. Allowing all methods to all routes is not.
Safety comes from scoping: route, method, actor, and rate.

3) Why does Gutenberg break when the REST API is blocked?

Gutenberg uses REST endpoints to fetch, autosave, validate, and manage blocks. If /wp-json/ returns HTML or 403/401, the editor can’t operate reliably.
The error message is often generic because the client expects JSON but gets something else.

4) What’s the difference between a 401 and a 403 for REST?

401 usually means “you didn’t authenticate (or your credentials are invalid).” 403 often means “you’re authenticated but not allowed,” or “a WAF is blocking you.”
In practice, security plugins and WAFs commonly use 403 for everything, so you must check headers and logs.

5) Can I just allowlist my integration server’s IP and call it done?

IP allowlists help, but they are not authentication. IPs change, NATs exist, and attackers can still hit your public endpoints.
Use real auth (application passwords, tokens) and treat IP allowlisting as an extra layer, not the only layer.

6) My REST API works on rest_route but not /wp-json/. What does that mean?

That points to rewrite/proxy routing issues, not REST being “disabled.” Fix nginx/Apache location rules, permalinks, or proxy path forwarding so /wp-json/ reaches WordPress.

7) Why does my WAF think REST requests are an attack?

Because many attacks do use predictable endpoints and automation patterns. REST traffic is often bursty, includes JSON, and hits routes that look like enumeration.
The solution isn’t to argue with the WAF; it’s to provide scoped exceptions for legitimate callers and keep the rest protected.

8) Should I block user endpoints to prevent user enumeration?

You should ensure sensitive user data is not publicly accessible. Modern WordPress already restricts much of it.
If you add WAF restrictions, do it precisely: block anonymous access to user enumeration routes, but don’t break authenticated admin/editor workflows.

9) Can caching REST endpoints improve performance safely?

Yes—for public, unauthenticated GET routes. Cache carefully and bypass cache for authenticated traffic (Authorization/cookies).
Never cache write responses, and watch for cached HTML block pages.

10) What if the security plugin blocks only certain custom endpoints?

That’s common. Custom endpoints often have unusual payloads or parameters that look suspicious.
Add route-specific exceptions or adjust the specific rule triggering the block; don’t blanket-allow all custom namespaces unless you’ve audited them.

Conclusion: next steps you can ship today

When the WordPress REST API is “blocked,” the fastest way out is to stop treating it like a single problem.
Identify the layer generating the response, confirm behavior at origin vs edge, and then implement a scoped allowance that matches your real use-case.
You’re not trying to win an argument with a firewall. You’re trying to make production predictable.

Practical next steps:

1. Run the header and origin-bypass tests to locate the blocking layer.
2. List the exact REST routes your app needs (read vs write).
3. Create a narrow WAF/security-plugin exception: path + method + actor constraints.
4. Verify caching rules: cache only safe public GET routes; bypass on Authorization/cookies.
5. Add monitoring for key REST endpoints and alert on spikes in 401/403/429/5xx.
6. Document the exception and schedule a review—exceptions have a way of becoming permanent infrastructure.