Configurar CORS en APIs de .NET

Cursos Empresas Blog Live Conf Precios

Contenido del curso

No sé dónde empezar

Fundamentos de APIs y .NET

Estructura de una Web API

Arquitectura y Middlewares

Tomar examen

Configurar CORS en APIs de .NET

Resumen

Cuando intentas consumir una API .NET desde otra aplicación, lo más común es toparte con un error de CORS que bloquea la petición. Aquí aprenderás a configurar Cross-Origin Resource Sharing en tu API .NET para permitir que clientes externos accedan a tus endpoints sin romper la seguridad de tu proyecto.

¿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 al servidor donde está alojada. Por defecto, las APIs en .NET no traen una configuración activa de CORS, así que cualquier origen externo queda bloqueado automáticamente.

¿Por qué funciona mi API en local pero falla desde otra app? Porque al probarla desde una aplicación de escritorio en la misma máquina no hay cambio de origen. En cuanto otra app intenta acceder desde un puerto o dominio distinto, CORS bloquea la petición.

Esto significa que mientras pruebes tu API contra sí misma todo parece correcto, pero al publicarla o al consumirla desde un frontend en React, Angular o cualquier cliente externo, vas a recibir el error de CORS en consola.

¿Cómo habilitar CORS en el archivo Program.cs?

La configuración inicial vive en Program.cs, que es el archivo principal donde registras servicios y middlewares. Ahí necesitas hacer dos cosas: registrar el servicio y aplicar el middleware.

Dentro del builder, agregas el servicio con AddCors, lo que carga todas las dependencias necesarias para que CORS funcione [01:32]. Luego, en la sección del app, defines el comportamiento que quieres permitir.

Una primera versión rápida luce así:

csharp builder.Services.AddCors();

app.UseCors(builder => { builder.AllowAnyHeader(); builder.AllowAnyOrigin(); });

Con AllowAnyHeader permites cualquier encabezado dentro del request, y con AllowAnyOrigin aceptas peticiones desde cualquier origen. Es la configuración más abierta posible.

¿Es seguro usar AllowAnyOrigin en producción?

No lo es. AllowAnyOrigin sirve para pruebas locales, pero en un ambiente productivo expone tu API a cualquier cliente. Lo correcto es definir explícitamente qué dominios o puertos pueden consumirla.

¿Qué hace AllowAnyOrigin exactamente? Le dice a tu API que acepte peticiones desde cualquier dominio, puerto o protocolo. Útil en desarrollo, peligroso en producción.

¿Cómo crear una política de CORS con nombre?

En lugar de inyectar la configuración directamente dentro del UseCors, lo más limpio es crear una política con nombre que puedas reutilizar y mantener ordenada.

El flujo es sencillo:

Declaras una variable con el nombre de la política, por ejemplo myAllowedOrigins.
Registras la política dentro de AddCors usando options.AddPolicy.
Aplicas esa política en el middleware con app.UseCors(myAllowedOrigins).

El código queda así:

csharp var myAllowedOrigins = "myAllowedOrigins";

builder.Services.AddCors(options => { options.AddPolicy(name: myAllowedOrigins, policy => { policy.AllowAnyHeader(); policy.AllowAnyOrigin(); }); });

app.UseCors(myAllowedOrigins);

Esta estructura es más organizada porque centraliza la configuración en un solo lugar. Si en el futuro necesitas cambiar las reglas, solo tocas el bloque de AddPolicy sin perseguir líneas dispersas en el código.

¿Cómo verifico que la política está funcionando?

Ejecuta la API y carga los datos desde el cliente. Si todo está bien, verás cómo el endpoint responde y los datos se actualizan en cada refresh. En el ejemplo de la clase, los datos cambian de forma aleatoria en cada carga, lo que confirma que la petición llegó correctamente al servidor.

¿Cómo restringir orígenes específicos con WithOrigins?

La práctica recomendada es especificar exactamente qué clientes pueden consumir tu API. Para eso usas el método WithOrigins, que recibe las URLs autorizadas.

La idea es reemplazar AllowAnyOrigin por algo así:

csharp policy.WithOrigins("http://localhost:3000") .AllowAnyHeader();

Además, lo ideal es que esos orígenes vivan en el archivo appsettings.json, no hardcodeados, para que puedas cambiar la configuración por ambiente sin recompilar.

¿Cuál es la diferencia entre AllowAnyOrigin y WithOrigins? AllowAnyOrigin abre la puerta a cualquier cliente. WithOrigins solo deja entrar a las URLs que tú definas. La segunda es la opción correcta para producción.

El reto: consumir tu API desde React

Para cerrar la práctica, crea una pequeña aplicación en ReactJS, que normalmente corre en el puerto 3000, y trata de consumir tu API .NET. Comenta el AllowAnyOrigin y configura WithOrigins para que solo ese cliente de React pueda acceder sin generar errores de CORS.

Es el ejercicio perfecto para entender cómo se comporta tu API frente a un frontend real y cómo afinar la seguridad sin sacrificar la funcionalidad. ¿Ya lo intentaste? Cuéntame en los comentarios qué orígenes configuraste y si te apareció algún error inesperado.

Andrés Muñoz

Estudiante

Saludos.

Comparto mi solución al reto de configuración de orígenes permitidos. El objetivo fue mover la seguridad al appsettings.json y validar la restricción con un cliente real. Aquí les dejo cómo lo logré:

1. Configuración de la API (.NET 10)

Primero, definí los dominios permitidos en el appsettings.json para evitar dejar valores fijos en el código:

{
  "AllowedOrigins": [ "http://localhost:3000" ]
}

Luego, en el Program.cs, leí esa configuración y apliqué la política usando .WithOrigins() en lugar de permitir todo:

var builder = WebApplication.CreateBuilder(args);

var allowedOrigins = builder.Configuration.GetSection("AllowedOrigins").Get<string[]>();
var MyAllowOrigins = "MyAllowOrigins";

builder.Services.AddCors(options =>
{
    options.AddPolicy(name: MyAllowOrigins,
        policy =>
        {
            policy.WithOrigins(allowedOrigins!) // Solo permite los de la lista
                  .AllowAnyHeader()
                  .AllowAnyMethod();
            // policy.AllowAnyOrigin(); 
        });
});

builder.Services.AddControllers();
builder.Services.AddOpenApi();

var app = builder.Build();

if (app.Environment.IsDevelopment())
{
    app.MapOpenApi();
}


app.UseCors(MyAllowOrigins);

app.UseHttpsRedirection();
app.UseAuthorization();
app.MapControllers();

app.Run();

2. Prueba de consumo con React

Para verificar que el origen localhost:3001 fuera aceptado, creé un pequeño cliente. Este es el código básico necesario en App.js para consumir el endpoint:

import React, { useEffect, useState } from 'react';

function App() {
  const [data, setData] = useState([]);

  useEffect(() => {
    fetch("https://localhost:7027/weatherforecast")
      .then(response => response.json())
      .then(json => setData(json))
      .catch(error => console.error("¡Error de CORS!", error));
  }, []);

  return (
    <div style={{ padding: '20px', fontFamily: 'sans-serif' }}>
      <h1>Probando conexión con .NET 10</h1>
      <ul>
        {data.map((item, index) => (
          <li key={index}>{item.date}: {item.summary}</li>
        ))}
      </ul>
    </div>
  );
}

export default App;

Puntos clave que aprendí:

La seguridad es mucho más fácil de gestionar si los orígenes están en la configuración y no en el código duro.
El orden del middleware app.UseCors() es crítico; si se pone después de los controladores, la petición será rechazada.
Ver el resultado en el navegador confirma que la API solo responde a quien nosotros autorizamos.

Miguel Teheran

Profesor

Esta solucion es correcta! felicitaciones!

Fundamentos de APIs y .NET

APIs REST profesionales desde cero

Requisitos para construir una API REST con .NET

Qué es una API REST y cómo funciona

Tu primera API con .NET desde cero

Estructura de un proyecto Web API en .NET

Cómo probar tu API con .http y Postman

Estructura de una Web API