The scenario highlights vulnerabilities in unmanaged packages where secrets (usernames, passwords, OAuth tokens) are stored in plain text and easily accessible. The goal is to protect these secrets from exposure in callouts, especially in unpackaged or unmanaged code contexts.

Why A (Protected Custom Metadata Types and Named Credentials)?

Named Credentials is the primary Salesforce-recommended mechanism for securely storing authentication details (including passwords, tokens, and secrets) for HTTP callouts. Secrets are encrypted, not visible in debug logs, and Salesforce handles authentication without exposing them in Apex code.

However, in Named Credentials, admins with "Customize Application" permission can view/edit the secrets.

To further protect secrets (e.g., hide them completely from admins or in packaged scenarios), use Protected Custom Metadata Types (preferably in a managed package). These allow Apex code in the same namespace/package to access the secrets while hiding them from users, API queries, or subscriber orgs.

This combination addresses both standard callouts (via Named Credentials) and cases needing maximum obfuscation (via Protected Custom Metadata), directly mitigating plain-text exposure in unmanaged packages.

Why not B (Encrypted Custom Fields and Protected Custom Settings)?

Encrypted Custom Fields are suitable for sensitive data like PII (e.g., credit cards, SSNs) but explicitly not recommended for storing authentication secrets or credentials used in callouts (per Salesforce Secure Coding guidelines).

Protected Custom Settings offer similar protection to Protected Custom Metadata but are less preferred for configuration-like data (secrets are configuration). Custom Metadata is deployable as metadata, better for packaging and migrations.

Why not C (Named Credentials and Protected Custom Settings)?

While Named Credentials are ideal, pairing with Protected Custom Settings is valid but suboptimal. Salesforce documentation and Trailhead modules favor Protected Custom Metadata Types over Custom Settings for secret storage due to better deployability, caching, and metadata API support.

This aligns with Salesforce Trailhead ("Securely Store Secrets with Salesforce Features") and secure coding guidelines, emphasizing Named Credentials for callouts and Protected Custom Metadata for high-security secret storage in packages. For unmanaged code vulnerabilities, migrating to these mechanisms (ideally with packaging) prevents exposure.