Dhruv_Naik
(Dhruv Naik)
November 19, 2025, 7:50am
1
Hi,
I want to know if there is a supported way to update Kibana Advanced Settings (specifically the defaultRoute attribute) using an API.
I’m trying to automate this through Jenkins so that each Kibana space gets a custom landing dashboard without manually changing it in:
Stack Management → Advanced Settings → defaultRoute
Hello @Dhruv_Naik
Welcome to the community!!
via devtools i see below request works :
=================
via DevTools
=================
PUT kbn:/api/saved_objects/config/9.0.2
{
"attributes": {
"defaultRoute": "/app/dashboards"
}
}
=================
via CURL
=================
curl -X PUT "http://localhost:5601/api/saved_objects/config/9.0.2" \
-H "Content-Type: application/json" \
-H "kbn-xsrf: true" \
-H "Authorization: ApiKey keydetail" \
-d '{
"attributes": {
"defaultRoute": "/app/dashboards"
}
}'
opened 03:23PM - 26 Sep 19 UTC
closed 08:20AM - 16 Jun 23 UTC
Team:Core
enhancement
### Proposal
The UI Settings Service should allow for individual settings to re… gister custom validators to prevent invalid values from being read or written.
There are several ways to configure an advanced setting today:
1) Through the Advanced Settings UI
2) Locked via `kibana.yml`'s `uiSettings.overrides.<key>`
3) Through the client-side UI Settings Service
4) Through the server-side UI Settings Service
5) Through manual changes to the underlying `config` object
We can (and should) enforce validation on `write` for methods 1 - 4 above. Since option 5 is technically possible, even if not supported, we will also need to account for the fact that invalid settings may exist on `read`, and fallback to the default setting value.
### Motivation
https://github.com/elastic/kibana/pull/44678 is introducing a new advanced setting to enable space-specific default routes. Previously, this setting was controlled by the `server.defaultRoute` option in `kibana.yml`.
Specifying this in the `yml` file ensured that only true admins had access to this configuration, and the schema validation (must start with a `/`) was sufficient enough to ensure that an obvious misconfiguration wasn't possible.
Now that this setting is moving to the Advanced Settings UI/UI Settings Service, is is trivial for any user with the appropriate privileges to accidentally misconfigure this setting. While the Advanced Settings UI comes with a warning that "you can break things here", we really should be providing some level of validation for each setting.
We ended up creating a ["default route service"](https://github.com/elastic/kibana/blob/515deb9ed26361ad4d515a28cea78bdc15cfc452/src/legacy/server/http/setup_default_route_provider.ts) in order to encapsulate this logic, otherwise it would need to be duplicated in OSS and X-Pack. If the UI Settings service allowed for validation, this service could be removed altogether, **and** it would enable a better user experience by preventing the setting from being accidentally misconfigured to begin with.
### Example:
`.kibana` index contains:
```json
{
"type": "config",
"config": {
"defaultRoute": "http://my-evil-kibana.com/app/gone_phishing"
}
}
```
Reading and blindly trusting this value would send users to another domain completely. If the `defaultRoute` setting could register a validator, we could ensure that the route is a valid relative url before using it, without having to manually check every place we need to use this value.
/cc @kobelb
Thanks!!
Dhruv_Naik
(Dhruv Naik)
November 19, 2025, 2:05pm
3
Hey @Tortoise thanks a lot, this helped me get it working
1 Like