CORS Header adds permissive Cross-Origin Resource Sharing headers to your responses, plus a fast path for OPTIONS preflight requests. Use it when an external front-end, mobile app, or browser tool needs to call your WordPress endpoints from a different origin.

What this feature does

By default, modern browsers block JavaScript on one origin from calling APIs on a different origin. This is the same-origin policy, and it’s a critical security boundary. To allow specific cross-origin calls, the receiving server must opt in by sending CORS headers like Access-Control-Allow-Origin.

WordPress doesn’t send those headers by default. If you have a headless front-end, a separate-domain admin tool, or a mobile app calling your REST API, you’ll see “CORS error” messages in the browser console. This setting writes a managed .htaccess block that adds the necessary headers and handles OPTIONS preflight requests with a fast 200 response.

CORS is not authentication

Allowing cross-origin requests doesn’t bypass WordPress’s authentication. Endpoints that require login still require login, regardless of CORS. CORS only tells the browser whether a response is allowed to be read by JavaScript on the calling origin. The headers AdminEase sets are permissive (Access-Control-Allow-Origin: *), so any origin can attempt the call; the response will only contain data the request actually has permission to read.

When you don’t need this

If your site is a normal WordPress install with a theme front-end and no separate apps calling its API, leave this off. CORS headers are only needed for cross-origin requests, which mostly happen with headless setups, integrations, and external tools.

How to enable it

  1. Open AdminEase › Security. Click AdminEase in the WordPress admin menu, then switch to the Security tab.
  2. Toggle CORS Header on. Save settings. AdminEase writes the rules to .htaccess immediately.
  3. Verify. Test from your external front-end or with curl: curl -I -H "Origin: https://example.com" https://yoursite.com/wp-json/. The response should include an Access-Control-Allow-Origin: * header.

Settings reference

Setting What it does Default
CORS Header Adds Access-Control-* headers to responses and a 200-fast-path for OPTIONS preflight requests. Off

What gets written to .htaccess

# BEGIN AdminEase
<IfModule mod_headers.c>
    Header set Access-Control-Allow-Origin "*"
    Header set Access-Control-Allow-Methods "GET, POST, PUT, DELETE, OPTIONS"
    Header set Access-Control-Allow-Headers "Content-Type, Authorization, X-Requested-With, X-WP-Nonce, Accept, Origin"
    Header set Access-Control-Allow-Credentials "true"
    Header set Access-Control-Max-Age "3600"
</IfModule>
 
<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{REQUEST_METHOD} OPTIONS
    RewriteRule ^(.*)$ $1 [R=200,L]
</IfModule>
# END AdminEase

The first block sets the actual CORS headers on every response. The second handles browser preflight requests: when a browser sends an OPTIONS request before a real cross-origin call, AdminEase short-circuits to a 200 response immediately, so PHP isn’t loaded for what’s essentially a metadata check.

Headers explained

Header Value What it controls
Access-Control-Allow-Origin * Which origins can read responses. * means any.
Access-Control-Allow-Methods GET, POST, PUT, DELETE, OPTIONS Which HTTP methods are allowed for cross-origin calls.
Access-Control-Allow-Headers Content-Type, Authorization, X-Requested-With, X-WP-Nonce, Accept, Origin Which request headers callers may send. Includes X-WP-Nonce for WordPress nonces.
Access-Control-Allow-Credentials true Whether the browser can send cookies and HTTP auth on cross-origin requests.
Access-Control-Max-Age 3600 How long browsers cache the preflight response (in seconds). One hour means fewer preflights.

Troubleshooting

The browser still shows a CORS error

Three things to check: confirm the master switch is on; confirm .htaccess is being read by your server (Nginx hosts ignore it); and check that no caching layer is stripping headers from the response. Run curl -I https://yoursite.com/wp-json/ and look for the Access-Control-* headers in the actual response.

I want to allow only specific origins, not *

The default value is * for simplicity. To lock it down, you’d need to customise the rule to whitelist specific origins. AdminEase doesn’t expose this in the UI, but you can override the generated rules by hooking the file handler from a small mu-plugin, or by adding your own Header set rule outside the AdminEase block in .htaccess.

Cookies aren’t being sent on cross-origin calls

Cookies require both Access-Control-Allow-Credentials: true (which AdminEase sets) and the calling JavaScript to opt in (e.g. fetch(url, { credentials: 'include' })). Also, browsers refuse to honour Allow-Credentials: true when Allow-Origin is *; if you need cookies, you must change the origin allow-list to a specific domain.

I’m on Nginx and CORS doesn’t work

Nginx ignores .htaccess. Ask your host to add equivalent add_header Access-Control-Allow-Origin "*"; directives to your Nginx server block.