Al consumir una API construida en .NET desde otra aplicación, es muy común toparse con un error de CORS que bloquea la petición. Aquí aprenderás qué es CORS, por qué ocurre ese bloqueo y cómo configurarlo correctamente en Program.cs para que tu API pueda ser consumida por clientes externos sin comprometer la seguridad.
¿Qué es CORS y por qué bloquea tu API en .NET?
CORS, o Cross-Origin Resource Sharing, es el mecanismo que define quién puede consumir tu API desde un origen distinto. Por defecto, una API de .NET no trae configuración activa de CORS, lo que significa que cualquier origen externo queda bloqueado automáticamente.
Esto explica por qué, mientras pruebas localmente desde una aplicación de escritorio en la misma máquina, todo funciona sin problema. En el momento en que otra aplicación, publicada externamente o corriendo en otro puerto, intenta navegar tu API, aparece el error.
¿Qué significa CORS? Cross-Origin Resource Sharing. Es una política del navegador que controla qué orígenes externos tienen permiso para hacer peticiones a tu API.
¿Cómo habilitar CORS en el archivo Program.cs?
La configuración se hace en dos lugares dentro de Program.cs: en la colección de servicios del builder y en el middleware del app [01:00].
Primero, dentro del builder, se registran las dependencias necesarias con AddCors. Esto prepara todo lo que CORS necesita para funcionar, pero aún no aplica reglas.
Luego, en la sección del app, se agrega el middleware UseCors con la política específica. En una primera versión rápida puedes escribir algo así:
csharp
app.UseCors(builder =>
{
builder.AllowAnyHeader()
.AllowAnyOrigin();
});
Aquí entran dos métodos clave:
AllowAnyHeader: permite que la petición llegue con cualquier tipo de encabezado.AllowAnyOrigin: acepta peticiones desde cualquier origen, sin importar el dominio o puerto.
Con esa configuración mínima, al ejecutar la API y volver a cargar datos desde el cliente, la respuesta llega sin errores. CORS ya está habilitado.
¿Por qué AllowAnyOrigin no es buena idea en producción?
Usar AllowAnyOrigin significa abrir tu API a cualquier aplicación en internet. Funciona perfecto para pruebas, pero en un ambiente productivo expone tu backend a clientes que no deberían tener acceso.
La práctica correcta es especificar exactamente qué orígenes pueden consumir la API, idealmente leyendo esa lista desde el archivo appsettings para no tener URLs quemadas en el código.
¿Cómo crear una política de CORS con nombre?
Una mejor forma de organizar la configuración es crear una política con nombre y reutilizarla en el middleware. Esto deja el código más limpio y permite manejar varias políticas si la API lo necesita.
El primer paso es declarar una variable que actúe como identificador de la política:
csharp
var myAllowedOrigins = "myAllowedOrigins";
builder.Services.AddCors(options =>
{
options.AddPolicy(myAllowedOrigins, policy =>
{
policy.AllowAnyHeader()
.AllowAnyOrigin();
});
});
Después, en el middleware, en lugar de pasar la configuración inline, basta con referenciar la política por su nombre:
csharp
app.UseCors(myAllowedOrigins);
Con esto, UseCors recibe un string que apunta a la política previamente registrada. La estructura queda más ordenada y más fácil de mantener.
¿Dónde se configura CORS en .NET? En Program.cs. Primero registras la política con builder.Services.AddCors y luego la activas en el pipeline con app.UseCors.
¿Cómo restringir orígenes con WithOrigins?
Cuando ya tienes la política con nombre, el siguiente paso es reemplazar AllowAnyOrigin por WithOrigins y listar solo las URLs autorizadas. Por ejemplo, una aplicación de React que normalmente corre en el puerto 3000 sería un origen específico que sí quieres permitir.
La configuración quedaría parecida a esto:
csharp
options.AddPolicy(myAllowedOrigins, policy =>
{
policy.WithOrigins("http://localhost:3000")
.AllowAnyHeader();
});
Idealmente, ese arreglo de orígenes no se escribe directamente en el código, sino que se lee desde appsettings.json, lo que permite cambiar dominios entre ambientes (desarrollo, staging, producción) sin recompilar.
¿Cómo probar la configuración con un cliente en React?
El reto práctico es montar una mini aplicación en ReactJS que salga por el puerto 3000 e intente consumir la API. Si configuraste WithOrigins correctamente con esa URL, la petición debería pasar sin error de CORS. Si la quitas o cambias el puerto, el navegador volverá a bloquearla, lo que confirma que la política está funcionando como filtro.
Algunos puntos a validar al hacer la prueba:
- La API responde datos distintos en cada refresh porque la fuente es aleatoria.
- El cliente React recibe respuesta solo si su origen está en la lista de
WithOrigins.
- Comentar
AllowAnyOrigin y dejar únicamente WithOrigins es la forma de comprobar que la restricción funciona.
Si ya implementaste tu propia política con WithOrigins y appsettings, cuéntame en los comentarios qué orígenes configuraste y cómo manejaste los distintos ambientes.
