[4.0] DB Credentials are exposed in the application API

[C-Lodder]

Steps to reproduce the issue

Use the following in your terminal:

curl -H "Authorization: Bearer YOUR_TOKEN" {{URL}}/api/index.php/v1/config/application

Or via JS:

fetch('{{URL}}/api/index.php/v1/config/application', {
  headers: {
    'Authorization': 'Bearer YOUR_TOKEN',
    'Content-Type': 'application/json',
  },
})
  .then(response => response.json())
  .then(data => console.log(data))

Expected result

DB credentials should not be returned in the API response

Actual result

Database credentials are exposed

Additional comments

It has been raised that that application API should be removed as site level configs should not be exposed at all.

@wilsonge @zero-24 @SniperSister

[zero-24]

Thanks will take a look into that issue over the weekend.

[brianteeman]

It has been raised that that application API should be removed as site level configs should not be exposed at all.

Why not?

[C-Lodder]

Quote from @mbabker

maybe certain aspects of it are "fine" as far as how sensitive the info might be, but the fact of the matter is the global application configuration is being exposed through a API based interface which is generally a red flag to me.

either way i'd advocate for just dumping that endpoint, to me it's too high risk to have that data available through an API but that's just me... if someone really thinks that application and component parameters should be configurable through an API instead of using the Joomla backend then they can add a plugin for that part of the system, but in general it seems like making that type of configuration readable (if not writable already, no idea what the API spec is) in that way is just asking for potential problems down the line

[alikon]

my usual dirt hack 😄
#29198

[zero-24]

Thanks for the PR @alikon.

Will let that one here open for @wilsonge to take a final decision on the point raised by @mbabker and @C-Lodder about removing that endpoint all together or keep it with the limits implemented by #29198

[zero-24]

I'm assigning the release blocker label for now. So this Issue is included and taken an decision on at least before the final version is out. As IIRC removing that endpoint later would be a B/C break right?

[mbabker]

As IIRC removing that endpoint later would be a B/C break right?

I'm fairly certain the Joomla development strategy does not reflect a policy regarding features of this type of API, but things that should be considered a B/C break include:

• The removal of data from an existing endpoint (i.e. removing database credentials from the application configuration endpoint after the release of 4.0)
• Changing an existing key in the response payload (i.e. renaming "created" to "created_at")
• The removal of an existing endpoint (i.e. GET support for the /api/index.php/v1/config/application endpoint is removed)

Therefore, any plans for removal of data and/or endpoints must be finalized prior to release as those types of changes should be considered breaking changes by any sane definition.

Additionally, even if after release it were decided to publish a /api/index.php/v2/config/application endpoint (where the API version is properly incremented) where data was removed from the response, the v1 endpoint would still be required to remain accessible until the application issues a major release which allows B/C breaking changes.

[zero-24]

When i get you right it is correct to mark this as release blocker so the decision is taken before stable is out right?

[wilsonge]

I deliberately made these accessible - it's ultimately super admin only anyhow (if it's not it should be). But I want to have every endpoint in Joomla having a corresponding API action.

[zero-24]

Ok so this can be closed as expected behavior now, right?

[mbabker]

I want to have every endpoint in Joomla having a corresponding API action

For content that makes sense. How many API providers routinely ship endpoints where application level configuration can be manipulated (even with ACL rules)? I think API endpoints allowing manipulation of com_config, and to a lesser extent com_installer and com_plugins (because those ultimately make changes at the application level) are a major red flag and need to be seriously scrutinized to decide if they actually provide a more tangible benefit than "if you can do it in the UI then there is an API endpoint for it".

[wilsonge]

Sure in drupal this is called the configuration API https://www.drupal.org/docs/8/api/configuration-api

I think com_installer installing extensions by file upload is more arguable than com_config tbh. I honestly don't see why APIs for taking your site offline etc wouldn't be something you would want (also turning on debug mode etc).

I'm also assuming we're talking about the application view in com_config - for component configuration I could give a much longer list of examples.

[mbabker]

That’s an internal application API (what Joomla would put in libraries), nothing there indicates that is exposed to a RESTful interface.

[wilsonge]

I think https://www.drupal.org/node/2724823 is the get requests.

I'm unclear as to whether they support updates. But that's largely based on the fact the many of the config entities don't support validation (obviously Joomla does) REF: https://www.drupal.org/project/drupal/issues/2300677

[C-Lodder]

Closing as it's intended