Configurar CORS en Apache: Guía Completa y Práctica

📅 Publicado el 31 de agosto, 2026 · Por Equipo RedServicio

¿Qué es CORS y por qué necesitas configurarlo en Apache?

Seguro que lo has visto. Estás desarrollando tranquilo, abres la consola del navegador y ahí aparece: «Access to XMLHttpRequest at ‘…’ has been blocked by CORS policy». Y de repente tu frontend, que vive en app.tudominio.com, no puede hablar con tu API en api.tudominio.com. Frustrante.

CORS, o Cross-Origin Resource Sharing, es un mecanismo de seguridad que implementan los navegadores mediante cabeceras HTTP. Por defecto, la same-origin policy impide que JavaScript lea recursos de un origen distinto al de la página. Lo que hace CORS es relajar esa restricción de forma controlada: el servidor declara explícitamente quién tiene permiso para acceder a sus recursos.

Requisitos previos para habilitar CORS en tu servidor

Antes de tocar nada, necesitas tres cosas (bueno, dos y media):

• Acceso al servidor Apache (físico, VPS o hosting compartido con acceso a .htaccess).
• El módulo mod_headers activado, porque sin él no hay caberas personalizadas.
• Tener claro qué dominios de tu aplicación necesitan acceso, y a qué rutas.

Verificar que mod_headers está activo

En Debian o Ubuntu, un comando te lo aclara:

• apache2ctl -M | grep headers — si aparece headers_module, ya está cargado.
• Si no aparece, actívalo con sudo a2enmod headers y reinicia Apache con sudo systemctl restart apache2.
• En CentOS/RHEL, el módulo suele venir habilitado de serie en el paquete httpd.

¿Hosting compartido? mod_headers normalmente está disponible y bastará con editar el .htaccess en la raíz del proyecto. Si tu proveedor lo restringe, eso ya te dice algo: necesitas un hosting más flexible. En RedServicio, por ejemplo, nuestros planes incluyen soporte 24/7 para este tipo de configuraciones sin complicaciones.

Cómo configurar CORS en Apache con .htaccess

La vía rápida es añadir la cabecera Access-Control-Allow-Origin en tu .htaccess:

Header set Access-Control-Allow-Origin «*»

Una sola línea y funciona. Acceso desde cualquier origen. Ojo, eso solo sirve para APIs públicas o entornos de desarrollo. En producción con credenciales, ni se te ocurra: el navegador rechaza el comodín si lo combinas con cookies o autenticación.

Permitir solo orígenes específicos

Para producción, lo correcto es restringir. Hay un detalle que suele pillar a todo el mundo: Apache no admite varios dominios en una sola cabecera. La solución pasa por una condición:

• Primero: SetEnvIf Origin «^(https://(app|www)\.tudominio\.com)$» ORIGIN_CORS=$1
• Luego: Header set Access-Control-Allow-Origin «%{ORIGIN_CORS}e» env=ORIGIN_CORS

Con esto, solo los orígenes que coincidan con el patrón reciben la cabecera. ¿Más dominios? Sepáralos con el carácter | dentro de la expresión regular y listo.

Soportar peticiones preflight (OPTIONS)

Aquí viene la parte que más gente olvida. Las peticiones con PUT o DELETE, o con cabeceras personalizadas, disparan antes una pre-flight request con método OPTIONS. Si no la respondes bien, todo se cae por detrás:

• Header always set Access-Control-Allow-Methods «GET, POST, PUT, DELETE, OPTIONS»
• Header always set Access-Control-Allow-Headers «Content-Type, Authorization, X-Requested-With»
• RewriteEngine On junto con una regla que responda 200 a OPTIONS, para que la petición no llegue a tu backend.
• Si usas credenciales (cookies, tokens), añade Header always set Access-Control-Allow-Credentials «true».

Configuración CORS en el archivo httpd.conf o VirtualHost

Si controlas el servidor entero, mejor definir CORS directamente en el VirtualHost. ¿Por qué? Rendimiento, sobre todo: Apache no tiene que procesar archivos por directorio. Y también claridad, porque toda la configuración queda en un solo sitio.

• Dentro de la sección <Directory /var/www/miapi>, añade las mismas directivas Header set descritas antes.
• Puedes limitar CORS a rutas concretas usando <LocationMatch «^/api/»>.
• Y ojo: aquí sí hay que reiniciar Apache tras cada cambio. sudo systemctl restart apache2 o httpd -k restart.

Errores comunes al configurar CORS en Apache

La cabecera aparece duplicada

Me ha pasado mil veces. Tu backend PHP ya envía Access-Control-Allow-Origin, Apache también, y el navegador protesta por valores múltiples. La cura: usa Header always unset Access-Control-Allow-Origin antes de volver a establecerla, o quita la cabecera en el código de la aplicación. Una u otra, no las dos.

El error persiste por caché

Navegadores y proxies cachean las respuestas preflight. Añade Header set Access-Control-Max-Age «86400» para reducir peticiones OPTIONS y, mientras pruebas cambios, trabaja en ventana de incógnito o directamente con curl:

curl -I -X OPTIONS -H «Origin: https://app.tudominio.com» -H «Access-Control-Request-Method: POST» https://api.tudominio.com/endpoint

Si la respuesta incluye las cabeceras correctas, el problema está en otro punto de la cadena (CDN, WAF o código). Seguir mirando el .htaccess ahí es perder el tiempo.

FAQ: preguntas frecuentes sobre CORS en Apache

• ¿CORS es solo cosa del servidor? Sí. El navegador aplica la política, pero la solución está en las cabeceras que envía tu Apache.
• ¿Puedo tener varios dominios permitidos? Sí, mediante SetEnvIf con expresiones regulares, como vimos arriba.
• ¿CORS afecta al SEO? No directamente, aunque una mala configuración puede romper recursos que tu web carga de terceros, y eso sí perjudica la experiencia de usuario.
• ¿Necesito reiniciar Apache al editar .htaccess? No. Apache lee ese archivo en cada petición. Solo reiniciarás si cambias el VirtualHost o el httpd.conf.

Conclusión

Al final, configurar CORS en Apache es sencillo una vez entiendes la lógica: el navegador exige cabeceras y tu servidor debe enviarlas de forma controlada. Verifica que mod_headers esté activo, define una lista blanca con SetEnvIf, gestiona bien el preflight con OPTIONS y comprueba el resultado con curl antes de dar nada por resuelto. Vigila también las cabeceras duplicadas y la caché de preflight, que son las dos fuentes más habituales de frustración. Si gestionas tus proyectos en un hosting con soporte 24/7 como el de RedServicio, cualquier duda con estas directivas se resuelve en minutos, no en horas. Y un CORS bien configurado no es solo que desaparezcan los errores de consola: es que tu arquitectura entre frontend y API funcione de forma segura, predecible y escalable.