Sensitive information disclosure: OAuth2 client secret exposed in admin settings (not masked)

Support
1

Issue Description

During a security review of our customized Discourse deployment, we found a potential sensitive information disclosure in the Admin > Settings interface regarding OAuth2 client secrets.

Details

  • In the admin configuration page, the OAuth2 client secret (and potentially other sensitive tokens/keys) are shown in plain text, rather than being masked (e.g. with asterisks).

  • Administrators are required to directly input the plain secret into the settings. Anyone with access to the admin UI can see the entire secret.

  • If an attacker gains access (even temporarily) to an admin session, they could easily obtain the client secret and use it for unauthorized OAuth2 token requests or to forge requests to third-party services.

Security Impact

  • Plain text exposure of secrets in the admin UI increases the risk of credential leakage.

  • The lack of masking is not in line with security best practices for handling secrets.

  • The secrets/tokens could be abused for privilege escalation, impersonation, or further attacks against integrated services.

Questions

  • Is there a plan to mask sensitive fields like OAuth2 secrets in the admin settings UI (e.g., display as ****** with the option to reveal if necessary)?

  • Are there recommended approaches or plugins to enhance the protection of sensitive credentials in Discourse deployments?

  • Has this issue been discussed previously? Any workarounds available until an official fix?

Thank you for your attention to this important security concern!

2

Hey @Evie_Tao
You are reporting lots of security concerns. Have you thought about reporting them on HackerOne, as itā€™s explained in the GitHub repository?

Security Overview Ā· discourse/discourse Ā· GitHub

1 Like
3

We donā€™t consider information disclosure to administrators a problem, but yes it should be marked as sensitive to avoid showing up unnecessariliy, the same as e.g. google_oauth2_client_secret.

This is a simple fix:

Thereā€™s a tradeoff of secrecy vs. convenience; not allowing the secrets to be unmasked in the UI would only provide an illusion of inaccessibility, thereā€™s other ways for an admin to easily read it from the database.

However, any secrets (any site setting really) can be specified via the environment, then they wonā€™t show up in the admin UI.

(right @pmusaraj?)