Your API reflects any Origin in Access-Control-Allow-Origin. Here is how to fix it.

What we observed during today’s test

During an API penetration test for a client today, one of our testers repeated a normal authenticated request with one header changed: Origin: https://evil.com. The API answered with that exact value in Access-Control-Allow-Origin, and with Access-Control-Allow-Credentials: true alongside it.

GET /api/v1/account/profile HTTP/1.1
Host: api.client-app.com
Origin: https://evil.com

HTTP/1.1 200 OK
Content-Type: application/json
Access-Control-Allow-Origin: https://evil.com
Access-Control-Allow-Credentials: true

evil.com is simply a placeholder for “a domain the client has never heard of”. The server was not checking the Origin at all; it was copying it. That single pattern switches off the browser’s main cross-origin protection for the whole API.

It is one of the most common CORS misconfigurations we report, and it usually arrives the same way. A developer hits a CORS error in local development, finds a snippet that makes the error disappear, and the snippet reflects the request’s Origin. It works, the ticket closes, and the setting ships to production unchanged.

How CORS is supposed to work

Browsers enforce the same-origin policy. JavaScript running on https://shop.example can send a request to https://api.other.example, but it cannot read the response. An origin is the combination of scheme, host and port, so https://app.example.com and https://api.example.com are different origins, and so are http:// and https:// versions of the same host.

Cross-Origin Resource Sharing (CORS) is how a server relaxes that rule deliberately. When a script makes a cross-origin request, the browser adds an Origin header naming the site the script came from. The server responds with Access-Control-Allow-Origin. If the value matches the requesting origin, the browser lets the script read the response. If it does not, the browser withholds it.

Several response headers control how much is shared:

Access-Control-Allow-Origin

The one origin allowed to read this response, or * for public resources

Access-Control-Allow-Credentials

When true, cookies and HTTP authentication are sent and the response is shared with the script

Access-Control-Allow-Methods

Methods allowed after a preflight, for example GET, POST, PUT

Access-Control-Allow-Headers

Request headers a script may send, for example Content-Type and Authorization

Access-Control-Expose-Headers

Response headers a script may read beyond the safe defaults

Access-Control-Max-Age

How long the browser may cache a preflight result, in seconds

For requests that are not “simple”, such as a PUT or a request with a JSON Content-Type, the browser first sends an OPTIONS preflight and only continues if the answer allows it.

The key idea: CORS does not protect your server from anyone. It is your server telling browsers which other websites it trusts with its users’ data. Reflecting the Origin tells browsers it trusts everyone.

Why a reflected Origin is a problem

The MDN CORS guide explains that for credentialed requests the server “must not specify the * wildcard” for Access-Control-Allow-Origin and must name an explicit origin. Teams that need cookies to work across origins discover that * fails, so they echo the incoming Origin instead. That satisfies the browser’s check for every site, including hostile ones.

When the response also allows credentials and the API authenticates with cookies, a page on an unrelated domain that a logged-in user happens to visit may be able to read that user’s API responses. PortSwigger’s write-up on CORS describes this class of issue in detail and notes the deciding factor: without Access-Control-Allow-Credentials: true, the browser does not send the user’s cookies, so other sites can only see what is already public.

How serious is it in your case?

Severity depends on a few facts you can check quickly. This is the way we rate the finding in our VAPT reports:

Related CORS misconfigurations to check at the same time

The reflected Origin is the most blatant version. While you are fixing it, look for these too, because they often sit in the same code:

Why this keeps happening

In our experience the reflected Origin almost never comes from a deliberate decision. It comes from one of a handful of shortcuts:

The common thread is that CORS errors are loud and CORS mistakes are silent. A broken policy produces red errors in the developer console and blocks the release. An over-permissive policy produces no error at all, so nobody notices until a penetration test or an incident.

CORS is not access control

One misunderstanding is worth correcting before the fix, because it leads teams to under- or over-react.

CORS only governs what browsers allow scripts on other websites to read. It does not stop anyone from calling your API directly. curl, Postman, a mobile app or a server-side script ignores CORS headers completely. So:

How to fix a CORS misconfiguration

The rule is the same in every framework:

Below is the secure version for the stacks we see most often. Replace the example origins with your own.

Nginx

A map block gives an exact allowlist without if statements. When the origin is not in the list, the variable is empty and Nginx does not send the header at all.

# http {} context
map $http_origin $cors_origin {
    default                     "";
    "https://app.example.com"   $http_origin;
    "https://admin.example.com" $http_origin;
}

server {
    location /api/ {
        add_header Access-Control-Allow-Origin      $cors_origin always;
        add_header Access-Control-Allow-Credentials "true" always;
        add_header Vary                              "Origin" always;

        if ($request_method = OPTIONS) {
            add_header Access-Control-Allow-Origin      $cors_origin always;
            add_header Access-Control-Allow-Credentials "true" always;
            add_header Access-Control-Allow-Methods     "GET, POST, PUT, DELETE" always;
            add_header Access-Control-Allow-Headers     "Content-Type, Authorization" always;
            add_header Access-Control-Max-Age           "600" always;
            add_header Vary                              "Origin" always;
            return 204;
        }
        proxy_pass http://app_upstream;
    }
}

Search your Nginx configuration for $http_origin used directly in add_header Access-Control-Allow-Origin. That line is the reflection.

Apache httpd

<IfModule mod_headers.c>
  SetEnvIf Origin "^https://(app|admin)\.example\.com$" CORS_ORIGIN=$0
  Header always set Access-Control-Allow-Origin "%{CORS_ORIGIN}e" env=CORS_ORIGIN
  Header always set Access-Control-Allow-Credentials "true" env=CORS_ORIGIN
  Header always merge Vary "Origin"
</IfModule>

The pattern is anchored at both ends and the dots are escaped, so look-alike domains do not match.

Node.js with Express and the cors package

The cors package reflects the request origin when you pass origin: true. That is the setting we find most often behind this issue. Use an array or a function instead:

import cors from 'cors';

const ALLOWED = new Set(['https://app.example.com', 'https://admin.example.com']);

app.use(cors({
  origin(origin, callback) {
    // Requests without an Origin header (server-to-server, curl) get no CORS headers
    if (!origin) return callback(null, false);
    callback(null, ALLOWED.has(origin));
  },
  credentials: true,
  methods: ['GET', 'POST', 'PUT', 'DELETE'],
  allowedHeaders: ['Content-Type', 'Authorization'],
  maxAge: 600,
}));

Also search the codebase for hand-written headers such as res.setHeader('Access-Control-Allow-Origin', req.headers.origin).

Spring Boot

@Bean
CorsConfigurationSource corsConfigurationSource() {
    CorsConfiguration config = new CorsConfiguration();
    config.setAllowedOrigins(List.of("https://app.example.com", "https://admin.example.com"));
    config.setAllowedMethods(List.of("GET", "POST", "PUT", "DELETE"));
    config.setAllowedHeaders(List.of("Content-Type", "Authorization"));
    config.setAllowCredentials(true);
    config.setMaxAge(600L);
    UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource();
    source.registerCorsConfiguration("/api/**", config);
    return source;
}

Watch for setAllowedOriginPatterns(List.of("*")) combined with setAllowCredentials(true). Spring then answers every origin with its own value, which behaves exactly like reflection.

ASP.NET Core

builder.Services.AddCors(options =>
{
    options.AddPolicy("Frontend", policy => policy
        .WithOrigins("https://app.example.com", "https://admin.example.com")
        .WithMethods("GET", "POST", "PUT", "DELETE")
        .WithHeaders("Content-Type", "Authorization")
        .AllowCredentials());
});

app.UseCors("Frontend");

SetIsOriginAllowed(_ => true) together with AllowCredentials() is the ASP.NET Core version of the reflected Origin. Replace it with WithOrigins.

Django and Flask

With django-cors-headers, list the origins and avoid the allow-all switch:

# settings.py
CORS_ALLOWED_ORIGINS = [
    "https://app.example.com",
    "https://admin.example.com",
]
CORS_ALLOW_CREDENTIALS = True
# Never in production together with credentials:
# CORS_ALLOW_ALL_ORIGINS = True

With Flask-CORS:

from flask_cors import CORS

CORS(app,
     resources={r"/api/*": {"origins": ["https://app.example.com", "https://admin.example.com"]}},
     supports_credentials=True)

Allowing many subdomains safely

Some products genuinely need dozens of origins, for example one subdomain per customer such as acme.app.example.com. Do not fall back to reflection. Use a single anchored pattern and keep it as strict as possible:

// Matches https://<one-label>.app.example.com and nothing else
const TENANT_ORIGIN = /^https:\/\/[a-z0-9-]{1,63}\.app\.example\.com$/;

function isAllowedOrigin(origin) {
  return origin === 'https://app.example.com' || TENANT_ORIGIN.test(origin);
}

The ^ and $ anchors stop prefix and suffix tricks, the escaped dots stop look-alike hosts, the character class stops nested subdomains, and requiring https:// rules out plain HTTP. Remember that every host matching the pattern is now trusted with your users’ data, so each one must be under your control and covered by the same security standards as the main application.

API gateways and CDNs

If CORS headers are added by AWS API Gateway, Azure API Management, Cloudflare or another edge service, fix them there as well. We often find the application fixed while the gateway still adds a permissive policy, or both layers add headers and the response ends up with two Access-Control-Allow-Origin values, which browsers reject. Decide on one layer that owns CORS and remove it from the others. A cloud security assessment reviews these edge configurations alongside the application.

How to test the fix

You do not need special tools. These curl checks confirm the policy from the outside. Run them against an endpoint that normally requires a session.

# 1. An unknown origin must get NO Access-Control-Allow-Origin header
curl -s -o /dev/null -D - https://api.example.com/api/v1/account/profile \
  -H "Origin: https://evil.com" | grep -i '^access-control'

# 2. A trusted origin must get its own value back, plus Vary: Origin
curl -s -o /dev/null -D - https://api.example.com/api/v1/account/profile \
  -H "Origin: https://app.example.com" | grep -iE '^(access-control|vary)'

# 3. Look-alikes and null must also be refused
for o in null https://notexample.com https://app.example.com.evil.com http://app.example.com; do
  echo "== $o"; curl -s -o /dev/null -D - https://api.example.com/api/v1/account/profile \
    -H "Origin: $o" | grep -i '^access-control-allow-origin'
done

Expected results: tests 1 and 3 print nothing; test 2 prints your trusted origin and vary: Origin. Repeat the checks for an OPTIONS preflight, because some frameworks handle preflights in a different code path.

Fix it now or later? A practical order of work

If you received this finding in a report today, this is the order we recommend:

Stop it coming back

CORS settings drift. A new service copies an old configuration, or someone adds localhost during an incident and never removes it. A few habits keep the fix in place:

Why this matters for audits

Auditors and enterprise security questionnaires increasingly ask for evidence of API testing, and a permissive CORS policy is a finding that maps directly to access-control requirements in SOC 2 and ISO 27001 assessments, and to OWASP’s guidance on security misconfiguration covered in our OWASP Top 10 guide. It is also quick to fix, which makes it an easy win to close before your next report.