Secrets and redaction

The rule for the whole plugin: an export must be safe to commit to a public git repository. Snapshots follow the same rule, because they store the same redacted document. A secret never reaches the snapshots table, a downloaded file, a diff or a REST response.

What a redacted value looks like#

A secret is replaced by the fixed text __awc_redacted__:

"core.writing": {    "mailserver_login": "__awc_redacted__",    "mailserver_pass": "__awc_redacted__",    "mailserver_url": "mail.example.com"}

The key stays in the file, so you can see that a secret exists. Only its value is gone. If the whole value is a group (for example every setting under a mail service's name), the whole group becomes the marker.

What gets redacted#

A value is redacted if any of these three rules match.

1. Keys a provider lists as secret#

Each source declares settings that are always secret, whatever they are called:

A dotted entry such as smtp.pass matches the end of a setting's path, at any depth.

2. Names that look secret#

Any setting, at any depth, whose name contains one of these words (any capitalisation) is redacted:

key, secret, token, pass (so also password), api, license, licence, salt, auth, credential, username or user_name, login, sid (only as a separate word, as in account_sid), webhook, dsn, private, bearer, cipher, cert.

Only the name is tested, never the value. The test is deliberately broad: it is better to redact something harmless than to leak something real. On a test site with Yoast SEO and Rank Math this rule alone caught google_api_key, index_now_key, myyoast-oauth, semrush_tokens and wincher_tokens.

3. Credentials inside a URL#

Any text value of the form scheme://user:password@host is redacted, whatever its setting is called.

Safe keys#

Because the name test is broad, some harmless settings would be caught by accident, such as the comment-moderation word list moderation_keys or a switch called noindex_password_protected. A source can list such settings as safe keys, which exempt them from rule 2:

• core.discussion: moderation_keys, disallowed_keys.
• plugin.yoast: anything named like author, keyword or keyphrase, plus license_server_version and remove_rest_api_links.
• plugin.rankmath: author-like names, capitalize_titles, noindex_password_protected.
• plugin.ase: author-like names.
• plugin.wp-mail-smtp: smtp.auth (a yes/no switch, not a password).
• WooCommerce groups: woocommerce_downloads_require_login, and in the accounts group woocommerce_registration_generate_password, woocommerce_registration_generate_username, woocommerce_enable_checkout_login_reminder, woocommerce_enable_signup_and_login_from_checkout and woocommerce_myaccount_lost_password_endpoint.

A safe key can be an exact name, a dotted path, or a pattern. A pattern only exempts a name that is still clean once the matched text is removed, so a safe pattern for author never hides a setting called author_api_key. Safe keys do not override rule 1 or rule 3: a key a source lists as secret, or a URL with a password in it, is redacted regardless.

What importing does with a marker#

Importing never writes the marker into your site.

• If the file has a marker for a setting your site already has, your site's current value is kept.
• If your site has no such setting, the marker is dropped and nothing is written.
• If a file simply omits a nested secret, your site's value is kept too. Importing cannot delete a secret.

In a diff, markers are never counted as changes. They are listed as redacted.

The consequence: moving settings from staging to live never carries staging's keys over, and never wipes live's keys. After you set up a new site, enter that site's own keys by hand.

What is never captured at all#

Redaction is the second line of defence. The first is that the plugin only reads settings from explicit lists. It does not scan the options table, so anything not on the supported list is not read:

• active_plugins, the list of installed or active plugins, is not a setting that can be exported or applied. The site block of an export shows plugin names and versions for information only, and the importer ignores it.
• Payment gateway settings (Stripe, PayPal, bank transfer and so on) are never captured. The WooCommerce sources cover only General, Products, Tax, Accounts and privacy, and Emails.
• WordPress salts, wp-config.php constants, users, passwords, orders, customers, posts, media and files.
• Environment settings (site URL, home URL, admin email, uploads path and URL) are left out unless you ask for them.
• Runtime state that plugins keep next to their settings, such as Yoast's indexing progress and activation timestamps, and the theme's custom_css_post_id and nav_menu_locations. These are skipped on export and preserved on import.