Skip to content
Web security Reviewed 2026-09-12

Cors Allow Origin Wildcard

What does this mean ?

Cross-Origin Resource Sharing (CORS) is a browser policy that controls which origins may read a response through browser APIs. An origin includes the scheme, hostname and port. CORS is not authentication, server-to-server access control or a complete CSRF defense.

A wildcard can be appropriate for a deliberately public resource without credentials. The risk is exposing a response to origins that should not read it, particularly when the browser sends credentials. Browsers do not allow Access-Control-Allow-Origin: * to authorize credentialed response access.

What can happen ?

Blindly reflecting the request's Origin and allowing credentials can let another website read private responses available to a signed-in user. A non-browser client can set its own Origin header, so the header must never determine whether the server authenticates a caller.

Recommendation

For a private browser API, configure a small set of exact trusted origins. Enable credentials only where required. Use the real serialized origin, such as https://app.example.com, not example.com or an arbitrary substring match. Do not broadly allow null origins.

When the allowed response origin varies, include Vary: Origin and a suitable private-response cache policy. Restrict preflight methods and headers to the route's needs. Continue to authenticate and authorize actual requests even when no Origin header is present. State changes using cookie authentication also need CSRF protection.

Sample Code

The examples illustrate a cookie-authenticated profile API used by one trusted web frontend. Replace the reserved example origin with the actual configured frontend. They do not themselves implement authentication or record authorization.

Express with the cors package:

import cors from 'cors';

const profileCors = cors({
  origin: 'https://app.example.com',
  credentials: true,
  methods: ['GET', 'POST'],
  allowedHeaders: ['Content-Type', 'X-CSRF-Token']
});

app.options('/profile', profileCors);
app.use('/profile', profileCors);
// Mount authenticated, authorized /profile handlers after this middleware.

The package handles CORS headers; this does not grant unauthenticated users access. Avoid a callback that simply returns every supplied origin as allowed.

ASP.NET Core CORS policy:

builder.Services.AddCors(options => options.AddPolicy("ProfileFrontend", policy =>
    policy.WithOrigins("https://app.example.com")
          .WithMethods("GET", "POST")
          .WithHeaders("Content-Type", "X-CSRF-Token")
          .AllowCredentials()));

// In the pipeline, after routing and before authorization:
app.UseCors("ProfileFrontend");

Apply the policy only to routes that need it, and retain their authorization requirements. Do not combine AllowAnyOrigin with AllowCredentials.

Spring MVC, with Spring Security's CORS integration configured when present:

@org.springframework.web.bind.annotation.CrossOrigin(
    origins = "https://app.example.com",
    methods = {org.springframework.web.bind.annotation.RequestMethod.GET,
               org.springframework.web.bind.annotation.RequestMethod.POST},
    allowedHeaders = {"Content-Type", "X-CSRF-Token"},
    allowCredentials = "true")
@org.springframework.web.bind.annotation.RestController
class ProfileController {
    // Authenticated and authorized handlers belong here.
}

An origin without its scheme does not express the intended browser origin.

A header fragment for an already authenticated private response; it does not process preflights:

$origin = $_SERVER['HTTP_ORIGIN'] ?? '';
header('Vary: Origin', false);
header('Cache-Control: private, no-store');
if ($origin === 'https://app.example.com') {
    header('Access-Control-Allow-Origin: https://app.example.com');
    header('Access-Control-Allow-Credentials: true');
}

Use a reviewed framework middleware for preflight handling. Never interpolate an arbitrary request Origin into the allow-origin header.

Regression checks

In a local browser fixture, verify the intended frontend can read its authorized response and an unrelated origin cannot. Cover scheme, port and subdomain lookalikes, null, missing Origin and preflight methods/headers. Independently assert that an unauthenticated request is denied even if it sends the allowed Origin header. Check that caches do not serve a private or wrong-origin response to another requester.

References