The http.cors.allow-origin setting in Elasticsearch controls which origins are allowed to make cross-origin requests to the Elasticsearch HTTP server. It is a crucial setting for enabling Cross-Origin Resource Sharing (CORS) in Elasticsearch.
Description
- Default value: None (CORS is disabled by default)
- Possible values:
*(allows all origins)- A comma-separated list of allowed origins
- Regular expressions to match origins
- Recommendations:
- For production environments, specify exact origins rather than using
* - Use this setting in conjunction with other CORS-related settings for comprehensive control
- For production environments, specify exact origins rather than using
This setting is available in all recent versions of Elasticsearch.
Example
To enable CORS for a specific origin:
PUT /_cluster/settings
{
"persistent": {
"http.cors.allow-origin": "https://example.com"
}
}
Reason for change: To allow a web application hosted on https://example.com to make direct requests to Elasticsearch.
Effect: The specified origin will be able to make cross-origin requests to Elasticsearch, subject to other CORS settings.
Common Issues and Misuses
- Setting
http.cors.allow-originto*in production environments, which can pose security risks - Forgetting to enable other necessary CORS settings, such as
http.cors.enabled - Mismatching the protocol (http/https) when specifying origins
Do's and Don'ts
Do's:
- Use specific origin URLs in production
- Combine with other CORS settings for complete control
- Regularly review and update allowed origins
Don'ts:
- Don't use
*in production environments - Don't enable CORS unnecessarily if not required
- Don't forget to set
http.cors.enabledtotruewhen configuring CORS
Frequently Asked Questions
Q: How do I allow multiple origins for CORS in Elasticsearch?
A: You can specify multiple origins as a comma-separated list in the http.cors.allow-origin setting, like this: "https://example1.com,https://example2.com".
Q: Can I use wildcards in the http.cors.allow-origin setting?
A: Yes, you can use regular expressions. For example, to allow all subdomains of example.com, you could use: /https?:\/\/.*\.example\.com/.
Q: Is it safe to set http.cors.allow-origin to * in production?
A: It's generally not recommended for security reasons. In production, it's better to explicitly list the allowed origins.
Q: Do I need to restart Elasticsearch after changing the http.cors.allow-origin setting?
A: No, if you change this setting using the Cluster Settings API, it will take effect immediately without requiring a restart.
Q: How does http.cors.allow-origin interact with other security settings in Elasticsearch?
A: While http.cors.allow-origin controls CORS, it doesn't override other security measures. You still need to configure authentication, authorization, and TLS/SSL for comprehensive security.
