Missing support to store secret_key (and site_key) outside of configuration (DB)

Created on 24 April 2025, about 13 hours ago

Problem/Motivation

Storing secrets in the configuration (DB) is usually considered a potential security issue. Thus it would be preferable to store secret_key (and site_key) elsewhere, e.g. settings.local.php (typically augmented by .env).

Unfortunately that's not possible right now because HCaptchaAdminSettingsForm extends ConfigFormBase and hcaptcha.settings is declared editable in its entirety. That in turn means overrides in settings.local.php are ignored.

Steps to reproduce

  1. Add the following to settings.local.php:
    $config['hcaptcha.settings']['site_key'] = 'SITE';
    $config['hcaptcha.settings']['secret_key'] = 'SECRET';
    
  2. Open /admin/config/people/captcha/hcaptcha to see that neither "Site key" nor "Secret key" are populated.
  3. Also, open /admin/config/people/captcha/examples to see that hCaptcha still renders the Math fallback, due to the missing keys.

Proposed resolution

As an admin I would like to be able to optionally override secret_key and site_key in settings.local.php in such a way that their values don't bleed into the configuration (DB). Ideally, an existing override would cause the corresponding field to render as read-only, while still showing the overridden value. Saving the admin form (for unrelated changes to other settings) must not save any overridden fields to avoid secrets leaking into the DB.

User interface changes

See above.

Please see the related issues for context. I know this is probably a core issue but looking at the history I doubt that the proposed solution above (which I consider the only solution to this general problem) is going to be implemented globally any time soon, so a local solution (a.k.a workaround) would be highly appreciated.

Thanks

Feature request
Status

Active

Version

1.0

Component

User interface

Created by

Live updates comments and jobs are added and updated live.
  • Security improvements

    It makes Drupal less vulnerable to abuse or misuse. Note, this is the preferred tag, though the Security tag has a large body of issues tagged to it. Do NOT publicly disclose security vulnerabilities; contact the security team instead. Anyone (whether security team or not) can apply this tag to security improvements that do not directly present a vulnerability e.g. hardening an API to add filtering to reduce a common mistake in contributed modules.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

Production build 0.71.5 2024