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 1m 8s —— View job

---

Review: centralize config obfuscation in ObfuscationUtil

• Read the diff (git diff origin/main...HEAD)
• Reviewed ObfuscationUtil, JVMInfoResource, SystemTableImpl, ConfigurationResource, and the test change
• Checked for behavior changes, null-safety, and dotCMS conventions

This is a clean extraction. The new ObfuscationUtil preserves the exact patterns (passw|pass|passwd|secret|key|token), the OBFUSCATE_SYSTEM_ENVIRONMENTAL_VARIABLES override, and the a*********z masking format. Consumers delegate correctly, and the deprecated statics in JVMInfoResource keep plugin compatibility.

Verified points:

• ConfigurationResource.isOnBlackList() — the old code null-checked JVMInfoResource.obfuscatePattern; matchesCustomPattern() drops the check, but Pattern.compile(...) never returns null, so semantics are identical. ✅
• SystemTableImpl no longer imports a REST class for security logging — good layering improvement. ✅
• Static-init ordering: obfuscateBasePattern = ObfuscationUtil.BASE_PATTERN triggers ObfuscationUtil class load, which reads Config — the test's mock-before-construct comment (updated correctly) still applies. ✅

New Issues

• 🟡 Medium: dotCMS/src/main/java/com/dotcms/util/ObfuscationUtil.java:62 — obfuscateIfNeeded does an unchecked (String) valueObject cast. All current callers pass String values (systemTable.all() is Map<String,String>, props.getProperty, env.get), so it's safe today. But the parameter is typed Object, inviting a non-String caller that would throw ClassCastException instead of masking. This matches the pre-existing behavior moved out of JVMInfoResource, so it's not a regression — worth hardening to String.valueOf(valueObject) while it's being centralized. Fix this →

Notes (non-blocking)

• The BASE_PATTERN/CUSTOM_PATTERN are compiled once at class-load, so a runtime change to OBFUSCATE_SYSTEM_ENVIRONMENTAL_VARIABLES won't take effect without a restart. This is identical to the prior JVMInfoResource behavior, so no change is needed — just noting the constraint is now the single source of truth.
• PR body says "no behavior change anywhere," but the getSystemTableInfo path (JVMInfoResource:116) switches from putAll (unmasked) to per-entry obfuscateIfNeeded. That masking is the fix carried from the stacked PR (Maintenance portlet: system config overrides displayed without obfuscation #36919/fix(security): obfuscate system config overrides in JVM info endpoint (#36919) #36920), so it's expected — just flagging the body wording for accuracy.

Nothing here blocks merge. The refactor is sound and improves layering.

· branch issue-36923-centralize-obfuscation