Plugin(cors):Assertion failure on empty origin header

[dingjiayi]

Is there an existing issue for this?

• I have searched the existing issues

Kong version ($ kong version)

Kong 3.9

Current Behavior

When I create a route with a CORS plugin specifying at least two allowed origins, and then attempt to access the route using curl with header.Origin=''(empty string)， receives empty reply from server.

Expected Behavior

Not empty reply.

Steps To Reproduce

1. Create a route with a CORS plugin.

Route Config:

{
  "preserve_host": false,
  "id": "737e3275-8a23-489d-a692-9307e01c3b83",
  "headers": null,
  "name": "echo-route-a",
  "service": {
    "id": "727d0f37-f96f-439a-b154-9953f039748c"
  },
  "strip_path": true,
  "request_buffering": true,
  "response_buffering": true,
  "https_redirect_status_code": 426,
  "protocols": [
    "http",
    "https"
  ],
  "snis": null,
  "path_handling": "v0",
  "destinations": null,
  "tags": [],
  "paths": [
    "/"
  ],
  "regex_priority": 0,
  "methods": null,
  "sources": null,
  "hosts": [
    "echo-test.com"
  ]
}

CORS Plugin:

{
  "id": "287d5fdc-1125-4af3-aa92-ec8dbdadbe4b",
  "protocols": [
    "http",
    "https"
  ],
  "instance_name": null,
  "consumer": null,
  "enabled": true,
  "tags": null,
  "config": {
    "exposed_headers": null,
    "headers": null,
    "origins": [
      "echo-test.com",
      "echo-test2.com"
    ],
    "preflight_continue": false,
    "max_age": null,
    "methods": [
      "GET",
      "HEAD",
      "OPTIONS"
    ],
    "private_network": false,
    "credentials": false
  },
  "service": null,
  "name": "cors",
  "route": {
    "id": "737e3275-8a23-489d-a692-9307e01c3b83"
  }
}

2. Create a request
   curl -ivv http://localhost:8000/ -H "Host: echo-test.com" -H "Origin;" (The header.Origin field is set to an empty string)

curl client info:

* Host localhost:8000 was resolved.
* IPv6: ::1
* IPv4: 127.0.0.1
*   Trying [::1]:8000...
* Connected to localhost (::1) port 8000
> GET / HTTP/1.1
> Host: echo-test.com
> User-Agent: curl/8.7.1
> Accept: */*
> Origin:
>
* Request completely sent off
* Empty reply from server
* Closing connection
curl: (52) Empty reply from server

Kong server error log:

failed to run header_filter_by_lua*: /usr/local/share/lua/5.1/kong/plugins/cors/handler.lua:34: invalid url
stack traceback:
	[C]: in function 'assert'
	/usr/local/share/lua/5.1/kong/plugins/cors/handler.lua:34: in function 'normalize_origin'
	/usr/local/share/lua/5.1/kong/plugins/cors/handler.lua:132: in function 'configure_origin'
	/usr/local/share/lua/5.1/kong/plugins/cors/handler.lua:245: in function </usr/local/share/lua/5.1/kong/plugins/cors/handler.lua:240>
	/usr/local/share/lua/5.1/kong/init.lua:465: in function 'execute_collected_plugins_iterator'
	/usr/local/share/lua/5.1/kong/init.lua:1633: in function 'header_filter'
	header_filter_by_lua(nginx-kong.conf:116):2: in main chunk while reading response header from upstream

Anything else?

The assertion failure at

kong/kong/plugins/cors/handler.lua

Line 34 in 6b9d32b

local parsed_obj = assert(url.parse(domain))

occurs when the domain parameter is an empty string. This appears to happen when the request origin (req_origin) is passed as an empty string through the CORS plugin logic.

Proposed Fix
We should add a check for empty origin values at:

kong/kong/plugins/cors/handler.lua

Line 194 in 6b9d32b

or not req_origin

kong/kong/plugins/cors/handler.lua

Line 250 in 6b9d32b

if not req_origin and not conf.allow_origin_absent then

By adding a condition req_origin ~= "" before processing the origin value, we can prevent empty strings from reaching the assertion check while maintaining valid CORS behavior.

If acceptable, I'd be happy to submit a PR to implement this fix.