01
Qué es y qué problema resuelve
CORS decide qué orígenes pueden leer respuestas mediante JavaScript en navegadores. No autentica usuarios ni bloquea clientes fuera del navegador.
Un origen incluye esquema, host y puerto, y debe definirse según el frontend real. Permitir cualquier origen amplía lectura pública cuando los datos y el modelo de credenciales lo permiten.
02
Ejemplo paso a paso
Punto de partida Fragmento para una API con bearer token y un portal ficticio. Ajusta orígenes y métodos a tu despliegue; el dominio de ejemplo no es un servicio disponible.
Antes de ejecutar
Requiere un host ASP.NET Core 10 preparado. builder y app corresponden a WebApplication.CreateBuilder y Build; las variables y tipos auxiliares deben definirse. Registra los servicios usados antes de Build. El ZIP de consola no contiene esta API.
builder.Services.AddCors(options => options.AddPolicy("Portal", policy =>
policy.WithOrigins("https://portal.example.test")
.WithMethods("GET", "POST")
.WithHeaders("Content-Type", "Authorization")));
app.UseCors("Portal");
// No se habilitan cookies ni credenciales en este ejemplo.Cómo funciona
- WithOrigins permite el origen específico del portal ficticio.
- La política restringe métodos y headers usados por el navegador.
- Comprueba que la autorización sigue siendo necesaria para cualquier cliente.
Resultado esperado: El navegador puede leer respuestas desde el origen permitido; la autorización sigue siendo responsabilidad de la API.
03
Cuándo usarlo y qué debes evitar
Si usas cookies entre sitios, debes evaluar además CSRF, SameSite y protección de solicitudes que cambian estado. Si permites credenciales en CORS, usa orígenes específicos; no combines credenciales con comodín.
El preflight tampoco demuestra que la operación de negocio esté autorizada.
Ampliación opcional · contexto y variantes del tema
CORS, límites y protección de recursos
CORS controla qué orígenes pueden leer respuestas desde un navegador; no evita que otro cliente llame a tu API ni es autenticación. Lista orígenes concretos cuando el navegador necesita acceso. Si usas credenciales, no combines origen comodín con esa política. Permite solo métodos y cabeceras necesarios; revisa preflight y llamadas normales.
Rate limiting restringe una dimensión de consumo. Un límite global evita una parte de la carga; una partición por usuario distribuye presupuesto; límites por IP requieren interpretar proxies de confianza y pueden agrupar usuarios legítimos detrás de una red. El limitador en memoria solo cubre una instancia. Para varias instancias considera un control compartido o de borde y documenta garantías.
Protege tamaño del cuerpo, longitud de filtros, número de resultados y tiempo de consultas. Un 429 indica rechazo por cuota; diseña reintentos con espera y evita un ciclo inmediato que empeore la carga. Ningún limitador sustituye índices, autorización o un presupuesto de trabajo por operación.
Punto de partida portal.example es un dominio ficticio. Sustitúyelo solo al integrar el entorno real. Esta política no incluye cookies ni habilita AllowCredentials.
Antes de ejecutar
Configuración ilustrativa de navegador
builder.Services.AddCors(opciones =>
opciones.AddPolicy("portal", politica => politica
.WithOrigins("https://portal.example")
.WithMethods("GET", "POST")
.WithHeaders("Authorization", "Content-Type")));
// Después de routing y antes de autorización:
app.UseCors("portal");Resultado esperado: El navegador permite los orígenes definidos; un cliente de consola aún necesita autorización.
04 · Práctica guiada · opcional
Practica lo aprendido
Compara una solicitud desde dos orígenes y una petición directa con un cliente HTTP.
- 01Prepara el ejemplo con las dependencias indicadas en «Antes de ejecutar».
- 02Compara una solicitud desde dos orígenes y una petición directa con un cliente HTTP.
- 03Comprueba y registra el resultado: El navegador puede leer respuestas desde el origen permitido; la autorización sigue siendo responsabilidad de la API.
Ver solución orientativa
Explica por qué el cliente directo no depende de CORS y comprueba que todos los clientes siguen necesitando permiso.
05
Comprueba lo aprendido
Responde antes de abrir la explicación. Esta comprobación es opcional y no guarda una puntuación.
01¿CORS protege la API frente a un cliente sin navegador?
No. Es una política aplicada por navegadores.
02¿Por qué una respuesta legible con un cliente HTTP directo no demuestra que CORS esté mal configurado?
CORS es una política que aplican navegadores al acceso desde otro origen. Un cliente HTTP directo no la aplica; la API sigue obligada a autenticar y autorizar según su contrato.
Cómo demostrar el objetivo
Compara tu práctica con estos resultados. Si solo diseñaste una prueba, registra su resultado como esperado, no como observado.
- Explicas el resultado esperado para origen permitido, otro origen y cliente directo.
- Mantienes autenticación y autorización para los clientes aunque CORS no intervenga.
Qué debes recordar
- CORS regula lectura entre orígenes en navegadores.
- La API debe autorizar todas las operaciones por separado.
Tu cuaderno · notas personales
Cuaderno local
Tus notas del contenido
Se guardan únicamente en este dispositivo. Puedes exportarlas cuando quieras.
Material de apoyo · descarga, glosario y referencias
Explicaciones, ejemplos y prácticas propios de Academia de Software. Los fragmentos de integración requieren las dependencias indicadas; el ZIP contiene el núcleo de consola. Las lecturas externas se consultan en su sitio original y conservan sus condiciones. Procedencia y condiciones de uso.