CORS errors WordPress: configurare correttamente
CORS (Cross-Origin Resource Sharing) regola le richieste tra origini diverse. Quando un sito frontend (es. app SPA) chiama l’API WordPress di un'altro dominio, CORS deve essere configurato. Errori CORS bloccano l’app. Vediamo il setup.
Cos'è CORS e quando serve
Per default il browser blocca XHR/fetch cross-origin per sicurezza. CORS permette al server di dire 'mi va bene se origin X mi chiama'. Caso tipico WordPress: app React su app.cliente.it chiama REST API su api.cliente.it. Serve Access-Control-Allow-Origin nell’header response. Senza, il browser blocca e in console appare 'CORS policy: No Access-Control-Allow-Origin'.
Setup in WordPress
Hook nell’init: header('Access-Control-Allow-Origin: https://app.cliente.it'). Per REST API c’è il filter dedicato: add_action('rest_api_init', function() { add_filter('rest_pre_serve_request’, function($value) { header('Access-Control-Allow-Origin: ...'); return $value; }); }). Mai usare * in produzione con credenziali.
Diagnosi con WP Error Monitor
Setta WPEM_TRACK_CORS=true: l’agent logga ogni OPTIONS preflight e gli header inviati. Se i preflight falliscono, vedi 'cors_preflight_failed’ nel CRM. La dashboard mostra: top origin che fanno richieste, top endpoint, errori per origin.
Preflight optimization con Max-Age
OPTIONS preflight viene ripetuto per ogni cross-origin request unless cached. Setta Access-Control-Max-Age: 86400 (24h) per cachare il preflight 24 ore. Riduce drasticamente overhead per app SPA che fa molte API calls. WP Error Monitor traccia preflight cache hit rate: se basso, sospetta header errato. Trade-off: cambi CORS config richiedono 24h per propagarsi a tutti i browser.
Wildcard subdomain con dynamic origin
Per supportare sottodomini di un dominio (es. tenant subdomain di SaaS), Access-Control-Allow-Origin non può essere wildcard se servono credentials. Soluzione: leggi HTTP_ORIGIN, verifica contro regex whitelist, setta dinamicamente. WP Error Monitor traccia origin viste e suggerisce pattern.
CORS preflight optimization
Preflight OPTIONS request precede ogni cross-origin con custom header. Per ridurre overhead: 1) Setta Access-Control-Max-Age=86400 (browser cacha preflight 24h), 2) Riduci custom header sul client (browser invia OPTIONS solo se header non-simple), 3) Usa solo metodi simple (GET, POST con Content-Type:text/plain) quando possibile. Tipica app SPA fa 100s preflight al giorno, ottimizzando riduci a 10s. WP Error Monitor traccia preflight count e cache hit ratio per identifying inefficiencies. Setup Access-Control-Allow-Methods stretti: lista solo i metodi davvero necessari per ogni endpoint.
CORS e cookies
Per request CORS che includono cookies, configurazione è più strict: 1) Access-Control-Allow-Origin NON può essere wildcard (deve essere specifico origin), 2) Access-Control-Allow-Credentials deve essere true, 3) Client side fetch deve avere credentials:'include'. Use case WP: app SPA cross-origin che usa cookie WordPress per auth. WP Error Monitor traccia 'cors_with_credentials' come pattern: numero richieste CORS con cookies. Se inaspettatamente alto, sospetta possibile CSRF: verifica SameSite cookie attribute (Lax o Strict consigliati per moderne app).
CORS testing checklist
Checklist testing CORS configurazione: 1) curl con header Origin verifica response include Access-Control-Allow-Origin appropriato, 2) curl OPTIONS verifica preflight response 200/204 con header corretti, 3) browser DevTools Network tab verifica nessun'errore CORS console, 4) test cross-browser (Chrome, Firefox, Safari) perché implementazioni differiscono leggermente, 5) test con/senza credentials, 6) test più origin se multi-tenant. Eseguire dopo ogni modifica config CORS. WP Error Monitor traccia CORS error patterns lato client se snippet attivo: utile per detect issue post-deploy senza dover testare manualmente.
Migration legacy CORS
Migration di applicazioni legacy senza CORS configurato richiede attenzione: aggiungere CORS troppo permissivo apre vulnerabilità. Strategia: header report-only equivalent (logging only) per 2 settimane, identifica pattern reali, applica config strict basato sui dati osservati invece di guess.
Procedura passo-passo
- Identifica le origin che devono accedere alla tua API.
- Crea mu-plugin cors-config.php con whitelist domain.
- Aggiungi handling OPTIONS preflight (return 204 vuoto).
- Setta header Access-Control-Allow-Methods, Allow-Headers.
- Se serve credentials cookie, setta Access-Control-Allow-Credentials: true.
- Setta WPEM_TRACK_CORS=true per monitoring.
- Genera traffico cross-origin e verifica zero blocchi in console.
- Esamina WP Error Monitor per eventuali preflight falliti.
- Setta Access-Control-Max-Age per cachare preflight.
- Implementa dynamic origin per multi-tenant SaaS.
Errori comuni e come risolverli
- Access-Control-Allow-Origin: * con cookies: Browser blocca per security: usa origin specifico o gestisci con whitelist dinamica.
- OPTIONS preflight 401: WordPress login required: aggiungi exception per OPTIONS in security plugin.
- CORS funziona da Postman ma non browser: Postman non rispetta CORS: il problema è solo browser-side.
- Max-Age ignorato: Browser limite max-age (Chrome 2h, Firefox 24h): non puoi ottenere più di quello.
- Wildcard subdomain non funziona: Regex troppo permissiva: usa pattern stretto.
Domande frequenti
D: Posso allowlist multiple origin?
R: Sì, con codice che verifica HTTP_ORIGIN contro array e setta dinamicamente.
D: CORS impatta sicurezza?
R: Setup bene non impatta: configurato male espone API a CSRF.
D: REST API ha CORS built-in?
R: Restituisce header restrittivi: usa filter rest_pre_serve_request per customizzare.
D: CORS bypass possibile?
R: Solo via proxy server-side (proxy aggira CORS browser).
D: Posso allow tutte le origin?
R: Solo per API publiche senza credentials: è la situation Access-Control-Allow-Origin asterisco.
Hai bisogno di aiuto?
Se vuoi affidare il monitoraggio WordPress al team di G Tech Group, scrivici tramite il modulo di contatto.