Do not enable Elasticsearch CORS with a wildcard

The fix/etc/elasticsearch/elasticsearch.yml

# The default and the right answer for most clusters:
http.cors.enabled: false

# If a browser app genuinely needs it, name exact origins — never '*':
# http.cors.enabled: true
# http.cors.allow-origin: "https://app.example.com"
# http.cors.allow-credentials: true

sudo systemctl restart elasticsearch

Why it matters

CORS decides which websites are allowed to make browser requests to your cluster. The dangerous configuration is the one that gets copied from old dashboard tutorials:

http.cors.enabled: true
http.cors.allow-origin: "*"        # any website, anywhere

That says: any web page a user visits may make requests to this Elasticsearch cluster from that user’s browser. If the cluster is reachable from the user’s network — an internal cluster and an employee browsing the web, or any cluster and an admin on the same machine — a malicious page can query indices, and if security is off, read and delete them.

It’s a specific and underappreciated way an “internal” cluster becomes reachable: you didn’t expose it to the internet, but you let the internet’s web pages reach it through the browsers of people who can.

Where it comes from

Old Elasticsearch browser tools — elasticsearch-head, dejavu, and various homegrown dashboards — run as static pages in the browser and talk directly to the cluster’s REST API. To work, they need CORS enabled, and the lazy configuration is allow-origin: "*".

Those tools are largely obsolete now — Kibana talks to Elasticsearch server-side, not from your browser, so it needs no CORS at all. But the setting outlives the tool. A cluster that once ran elasticsearch-head in 2019 may still have http.cors.allow-origin: "*" in its config, doing nothing useful and standing open.

If you actually need it

Some legitimate single-page applications query Elasticsearch directly. If yours does, name the exact origins:

http.cors.enabled: true
http.cors.allow-origin: "https://app.example.com"
http.cors.allow-methods: "GET, POST"
http.cors.allow-credentials: true

Two rules:

• Never *, and never a regex broader than you can defend. allow-origin accepts a /regex/ — a sloppy one like /https?://.*\.example\.com/ can match evil.example.com.attacker.net depending on how it’s written.
• allow-credentials: true cannot be combined with allow-origin: "*" by the browser’s own rules — which is a hint from the web platform that wildcard plus credentials is exactly the combination that shouldn’t exist.

Better still: put the browser app behind your own backend, which talks to Elasticsearch server-side with a scoped API key. Then the cluster needs no CORS and the key never reaches the browser.

Verify it worked

Check the setting on the running node:

curl -sk -u elastic https://localhost:9200/_nodes/settings?filter_path='**.http.cors' 2>/dev/null
grep -E 'http.cors' /etc/elasticsearch/elasticsearch.yml

Then test it the way a malicious page would — send an Origin header and see if the cluster blesses it:

curl -sk -u elastic -H "Origin: https://evil.example" \
  https://localhost:9200/ -D - -o /dev/null | grep -i 'access-control-allow-origin'

Access-Control-Allow-Origin: *, or the header echoing back https://evil.example, is the finding — the cluster is telling arbitrary origins they’re allowed.

No access-control-allow-origin header at all means CORS is off, which is the goal for most clusters.

Look for the old tools that needed it, in case one is still deployed:

grep -rEl 'elasticsearch-head|_plugin/head|dejavu' /etc /opt /var/www 2>/dev/null

Before you apply this

Disabling CORS breaks any browser application that queries the cluster directly — but not Kibana, which never used it, and not your server-side applications, which don’t make browser requests. The only things affected are in-browser tools talking straight to port 9200.

Before turning it off, confirm nothing legitimate depends on it:

# Are there requests carrying an Origin header from a real app?
sudo journalctl -u elasticsearch | grep -i origin | tail

If a real single-page app needs it, switch from * to its exact origin rather than disabling entirely — that keeps the app working while closing the wildcard.

Narrowing allow-origin from * to a specific origin is safe for everything except the pages that were relying on the wildcard, which by definition were any page. If a legitimate app breaks, it will be because it’s served from an origin you didn’t list — add that origin, don’t go back to *.

Note CORS is a browser control: it does nothing against a direct API client like curl or a server. It is not a substitute for authentication, binding or a firewall — it only governs what browsers will do on behalf of a page. A wide-open CORS on a properly authenticated, firewalled, internal cluster is lower risk than it looks, but it’s free to close and there’s no reason to leave a * sitting there.

Related

• Enable security — CORS is worst when there’s no auth behind it.
• API keys and least privilege — the server-side alternative to browser access.