Skip to content

Obfuscate credentials before rendering to the front-end#1047

Merged
peterwilsoncc merged 11 commits intodevelopfrom
feature/obfuscate-credentials
Feb 10, 2026
Merged

Obfuscate credentials before rendering to the front-end#1047
peterwilsoncc merged 11 commits intodevelopfrom
feature/obfuscate-credentials

Conversation

@dkotter
Copy link
Collaborator

@dkotter dkotter commented Feb 9, 2026

Description of the Change

At the moment, we grab all settings when rendering our settings page. This includes any Provider credentials that have previously been saved. This allows us to populate those credential fields with saved values so if any additional saves happen, we don't lose those credentials.

The issue here is that means these credentials are rendered in plain text, both in the API response that gets our settings and in the text inputs themselves. This isn't a huge deal as only administrators have access to these setting pages but it still isn't ideal.

This PR fixes that by adding in an CredentialObfuscator class that will take all the settings we have saved and will then obfuscate just the private credential fields (like API keys). This only happens when we get our settings to display, not when we get the settings to use in API requests. We then check that we don't have obfuscated credentials when saving and if we do, we ignore those credentials (so we don't save obfuscated credentials).

How to test the Change

  1. Add credentials for one or more Providers and save those
  2. Refresh the page and then inspect the source, ensuring the value of the text input is obfuscated
  3. Can also refresh the page and inspect the network requests to ensure the response from our settings endpoint returns obfuscated credentials
  4. Ensure that if you re-save a previously configured Provider that the obfuscated credentials aren't saved to the database and the Provider continues to work

Changelog Entry

Security - Add a CredentialObfuscator class that will obfuscate any private credentials before rendering those.

Credits

Props @dkotter

Checklist:

@dkotter dkotter added this to the 3.8.0 milestone Feb 9, 2026
@dkotter dkotter self-assigned this Feb 9, 2026
@dkotter dkotter requested review from a team and jeffpaul as code owners February 9, 2026 14:49
@github-actions github-actions bot added the needs:code-review This requires code review. label Feb 9, 2026
@dkotter dkotter requested review from peterwilsoncc and removed request for a team and jeffpaul February 9, 2026 14:50
@github-actions
Copy link

github-actions bot commented Feb 9, 2026

✅ WordPress Plugin Check Report

✅ Status: Passed

📊 Report

All checks passed! No errors or warnings found.


🤖 Generated by WordPress Plugin Check Action • Learn more about Plugin Check

Copy link
Contributor

@peterwilsoncc peterwilsoncc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A couple of suggestions inline.

They're both fairly paranoid so I'm happy to hear any push back.

Otherwise the code looks good and is testing well.

@jeffpaul jeffpaul mentioned this pull request Feb 10, 2026
28 tasks
Copy link
Contributor

@peterwilsoncc peterwilsoncc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I pushed one last paranoid length check in f16a21d.

This is testing well and the code looks good to merge.

@peterwilsoncc peterwilsoncc merged commit 945ec01 into develop Feb 10, 2026
18 checks passed
@peterwilsoncc peterwilsoncc deleted the feature/obfuscate-credentials branch February 10, 2026 23:27
@github-project-automation github-project-automation bot moved this from QA Testing to Done in Open Source Practice Feb 10, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

needs:code-review This requires code review.

Projects

Archived in project

Development

Successfully merging this pull request may close these issues.

3 participants