refactor(security): centralize config obfuscation rules in ObfuscationUtil (#36923)

[wezell]

Proposed Changes

Extracts the sensitive-config masking rules into a single authoritative home, com.dotcms.util.ObfuscationUtil:

• DEFAULT_OBFUSCATE_PATTERN (passw|pass|passwd|secret|key|token), the always-on BASE_PATTERN, and the config-driven CUSTOM_PATTERN (OBFUSCATE_SYSTEM_ENVIRONMENTAL_VARIABLES)
• shouldObfuscate(), matchesCustomPattern(), obfuscateIfNeeded(), obfuscate()

Consumers updated:

• JVMInfoResource — uses the utility; its previously-public statics (obfuscateBasePattern, obfuscatePattern, obfuscateIfNeeded) remain as thin @Deprecated delegates since plugins may reference them
• SystemTableImpl.set() — security logging no longer depends on a REST class
• ConfigurationResource.isOnBlackList() — uses matchesCustomPattern() (identical semantics to its previous direct pattern read)

No behavior change anywhere — same patterns, same a*********z masking format.

Stacked on #36920 (config-overrides obfuscation fix — same file); merge that first and this diff shrinks to the refactor only.

Checklist

• Tests (ConfigurationResourceTest updated comment; behavior unchanged, existing coverage applies)
• Translations (n/a)
• Security Implications Contemplated (refactor of security masking; no rule changes)

🤖 Generated with Claude Code

This PR fixes: #36923

[claude]

Claude finished @wezell's task in 5m 53s —— View job

---

Code Review — centralize config obfuscation

• Read the diff and changed files
• Verify all consumers of removed members
• Check semantics preservation
• Post review

Solid, well-contained refactor. Behavior is preserved across all consumers, and keeping the old JVMInfoResource statics as @Deprecated delegates is the right call for plugin compatibility. A few notes below.

New Issues

• 🟡 Medium: dotCMS/src/main/java/com/dotcms/rest/api/v1/maintenance/JVMInfoResource.java:9 — import com.dotmarketing.util.Config; is now unused. Its only references were the inline Config.getStringProperty(...) pattern-compile calls that moved to ObfuscationUtil. Remove the import to keep the file clean. Fix this →

Notes (non-blocking)

• isOnBlackList null-check dropped is safe. The old null != JVMInfoResource.obfuscatePattern ? ... : false guard is gone in favor of ObfuscationUtil.matchesCustomPattern(key). CUSTOM_PATTERN is a static final Pattern that can never be null — if the config value were somehow null, Pattern.compile(null) would throw at class-load, not yield a null field. So the previous ternary's null branch was dead code; semantics are identical. ConfigurationResourceTest already mocks Config before class load to cover this.
• Import ordering nit (skip if you like): in both JVMInfoResource.java:5 and ConfigurationResource.java:8, the new com.dotcms.util.ObfuscationUtil import is placed mid-block among com.dotcms.rest.* imports rather than in alphabetical position. Purely cosmetic.
• obfuscate() widened to public. In the old code it was private; in ObfuscationUtil it's public. Reasonable for a util class, and it assumes a non-empty value (guarded by obfuscateIfNeeded). No caller in this diff invokes obfuscate() directly, so no new blast radius — just flagging the visibility change was intentional.

Test coverage

Behavior is unchanged and the existing ConfigurationResourceTest continues to exercise the path through matchesCustomPattern. Given ObfuscationUtil is now the single authoritative home for masking, a small direct unit test (shouldObfuscate / matchesCustomPattern / masking format s*********t) would be worth adding to lock the contract — non-blocking.

Nothing here blocks merge; the only real cleanup is the unused Config import.
· issue-36923-centralize-obfuscation