Why API keys shouldn’t travel in a settings export

A WordPress settings export is designed to make configuration portable. An API key is designed to remain secret.

Putting both inside the same export file creates a fundamental conflict.

Imagine that a plugin exports its configuration as JSON:

{
  "feature_enabled": true,
  "model": "example-model",
  "language": "en",
  "api_key": "secret-api-key"
}

The first three values are configuration.

The API key is a credential.

Those two classes of data should not automatically travel together.

A settings export may be:

• downloaded to an administrator’s computer;
• sent to a colleague;
• attached to a support ticket;
• stored in cloud storage;
• placed in a shared project folder;
• copied to a staging site;
• imported into a client’s website;
• committed accidentally to a repository;
• included in another backup;
• kept indefinitely after its original purpose has ended.

If the export contains API keys, every copy becomes another copy of the secret.

That dramatically increases the number of places from which the credential can be exposed.

The problem is not limited to AI API keys. The same principle applies to many sensitive values, including:

• payment gateway credentials;
• SMTP passwords;
• webhook signing secrets;
• OAuth client secrets;
• private API tokens;
• cloud service credentials;
• database passwords;
• private integration tokens.

The OWASP Secrets Management Cheat Sheet identifies API keys, database credentials, SSH keys, certificates and similar credentials as secrets that require controlled storage, provisioning, auditing and rotation.

Google’s current API key security guidance similarly recommends preventing keys from being exposed in source repositories, isolating credentials, restricting their scope and rotating them when necessary.

A portable WordPress settings file should therefore carry the configuration needed to reproduce behavior without silently becoming a portable credential bundle.

Configuration and secrets are different types of data

The first step is understanding what a settings export is supposed to represent.

Configuration describes how an application should behave.

Examples include:

• whether a module is enabled;
• which post types a feature applies to;
• a preferred language;
• a selected model name;
• interface preferences;
• role configuration;
• visibility rules;
• formatting options;
• feature-specific thresholds.

These values are often useful on another WordPress installation.

A secret does something different.

It proves possession of access to another system.

An API key is usually a bearer credential

Many API keys work on a simple principle: possession of the key allows the caller to make requests associated with the account, project or service to which that key belongs.

Google’s API key guidance explicitly warns that exposed keys can lead to unauthorized access or unexpected charges.

That means an API key is not merely another preference such as:

temperature = 0.7

or:

language = en

It represents authority.

If someone obtains the key and the provider accepts it, the person may be able to use the associated API within the permissions and restrictions attached to that credential.

Portable configuration should describe behavior, not transfer authority

If you export:

• the selected AI model;
• the output language;
• the enabled modules;
• the configured role rules;

another site can reproduce those settings.

But the destination should normally provide its own credentials.

That keeps two independent questions separate:

• How should this site behave?
• Which credential is this site authorized to use?

Why settings exports increase the exposure surface

A secret stored in one controlled location already needs protection.

Putting the same secret into an export creates another copy.

Making five exports creates five additional copies.

Sending those exports elsewhere multiplies the problem further.

Exports are designed to move

A configuration export exists specifically because someone intends to move it somewhere.

That might be from:

• production to staging;
• one client site to another;
• a development site to production;
• one administrator to another;
• an existing project into a reusable agency template.

This portability is useful for settings.

It is undesirable for secrets unless the transfer has been explicitly designed as a secure credential-transfer operation.

Every additional secret copy creates another place to protect

Consider one API key stored only in the production site’s configuration.

You may need to secure:

• the WordPress database or secret store;
• administrator access;
• server backups.

Now imagine the key also appears in:

• three settings exports;
• one email attachment;
• a shared Drive folder;
• a developer’s Downloads folder;
• a staging database after import;
• a support ticket attachment.

The credential has not become more secure because every copy contains the same secret.

The number of places capable of leaking it has simply increased.

Exports often outlive their purpose

A settings file may be useful for five minutes and remain stored for five years.

That is particularly dangerous for credentials because forgotten copies can survive long after everyone has stopped remembering that the file contains sensitive information.

This is one reason secrets management focuses not just on storage but also on lifecycle, rotation and revocation.

Why copying credentials between WordPress sites is risky

A settings export is often imported specifically because the destination site should resemble the source site.

That does not mean the two sites should necessarily share credentials.

Production and staging should not automatically share secrets

Suppose you export production settings and import them into staging.

If the API key is included, the staging site may now be able to use the same external service identity as production.

This can create several problems:

• testing may consume production API quotas;
• development requests may create real charges;
• a less protected staging environment now holds a production credential;
• logs from separate environments become harder to distinguish;
• revoking one shared key affects both environments.

A better design is usually:

• production uses a production credential;
• staging uses a staging or restricted credential;
• local development uses another appropriate credential or no live credential at all.

For broader environment isolation practices, see WordPress Staging Site Best Practices.

Client sites should not inherit another client’s credentials

This becomes even more important for agencies.

A WordPress configuration export can be an efficient starting point for multiple client websites.

That is exactly the sort of workflow discussed in Standardizing WordPress Configuration Across Client Sites.

But if secrets travel with that standard configuration, the template can accidentally distribute:

• your agency’s credentials;
• another client’s credentials;
• production credentials intended for only one installation.

The configuration may be reusable.

The authorization usually is not.

API keys should follow least privilege

Keeping credentials separate from exports also makes it easier to follow the principle of least privilege.

Google recommends restricting API keys both by the services they may access and, where supported, by the applications, IP addresses, websites or other environments allowed to use them.

The goal is to reduce the potential damage if a key is exposed.

Different environments can have different restrictions

A production key might be restricted to:

• specific APIs;
• a production server IP;
• a particular domain;
• an expected application.

A staging key may have:

• lower quotas;
• different API access;
• a staging-domain restriction;
• fewer permissions.

When every site receives the same credential through a settings export, those boundaries become much harder to maintain.

Separate credentials improve attribution

Individual credentials can also make it easier to understand where API traffic originates.

If ten websites all use one shared key, usage logs may tell you that the key was used without clearly identifying which installation generated the request.

If each environment uses a separate credential, monitoring, incident response and revocation become more precise.

Encryption does not automatically make secret exports a good design

A natural response is: why not encrypt the settings export?

Encryption can be valuable, but it changes the threat model rather than eliminating the architectural question.

An encrypted export needs another secret

To decrypt an encrypted file, the destination needs a key or password.

That introduces another problem:

How will the decryption secret be transferred securely?

If the encrypted export and its password are sent through the same channel, much of the benefit may disappear.

The destination still receives the credential

Even if transport is perfectly encrypted, importing the file eventually reveals the API key to the destination environment.

That may be appropriate for a purpose-built credential migration workflow.

But it is usually unnecessary for an ordinary settings export whose job is simply to reproduce configuration.

Minimize secret export rather than protecting unnecessary copies

OWASP’s secrets-management guidance emphasizes reducing unnecessary exposure, controlling access and managing secret lifecycles.

If a settings export does not need an API key to perform its purpose, the strongest design is generally not:

include it, then invent increasingly elaborate protections for the exported copy.

It is:

do not put the key in the export.

What should a safe settings export contain?

A useful settings export should contain enough information to recreate configuration while avoiding values tied to one environment or security context.

Good candidates for portability

Depending on the plugin, these may include:

• feature enable/disable states;
• layout preferences;
• role mappings;
• selected post types;
• UI settings;
• content-processing rules;
• SEO defaults;
• module configuration;
• non-sensitive integration options.

Poor candidates for automatic portability

These often include:

• API keys;
• passwords;
• private tokens;
• OAuth client secrets;
• webhook signing secrets;
• temporary authentication values;
• session material;
• environment-specific runtime state;
• activity logs;
• site-specific caches.

The exact boundary depends on the application, but the principle remains useful:

Export the configuration required to recreate behavior, not every value that happens to exist in the options table.

Allowlisting exportable settings is safer

One robust approach is to define exactly which option groups belong in an export.

That is safer than blindly serializing every plugin option and then hoping someone remembered every secret that needed removal.

A conceptual implementation might look like:

$exportable = [
    'general_settings',
    'role_settings',
    'interface_settings',
    'feature_settings',
];

foreach ( $exportable as $option_name ) {
    $export[ $option_name ] = get_option( $option_name );
}

Even with an allowlist, nested configuration should still be reviewed for sensitive values.

Secrets should be re-entered or provisioned separately

Once secrets are excluded from the export, the destination site needs another way to obtain them.

That is intentional.

Manual re-entry is sometimes appropriate

For a relatively small WordPress installation, the simplest secure workflow may be:

1. import the portable settings;
2. open the integration settings;
3. enter the destination site’s API key;
4. save the configuration;
5. test the connection.

This creates a small amount of friction, but that friction occurs exactly where an authorization boundary exists.

Infrastructure-managed secrets scale better

Larger deployments can provision secrets separately through infrastructure designed for credential management.

Depending on the environment, that may involve:

• a secrets manager;
• protected server configuration;
• deployment-time injection;
• host-specific configuration;
• another controlled credential store.

OWASP recommends centralizing secret storage and lifecycle management where practical rather than scattering credentials through source code and configuration systems.

Be careful with simplistic environment-variable advice

Environment variables are frequently recommended because they keep credentials out of application source code.

They can be useful, but they are not automatically a secret vault.

OWASP’s cryptographic-storage guidance notes that environment variables may themselves become exposed through debugging information or operating-system interfaces in some environments.

The broader principle is therefore more useful than one universal storage mechanism:

store the secret in the most controlled mechanism appropriate to the hosting architecture, and keep it out of ordinary portable configuration.

What to do if an API key was already exported

If you discover that a settings export contained a real API key, deleting the export is useful but may not be sufficient.

You need to consider where the file may already have travelled.

Identify every known copy

Check whether the export was:

• emailed;
• uploaded to support;
• stored in cloud storage;
• committed to Git;
• shared through chat;
• imported into staging;
• copied to another client’s site;
• included in backups.

Rotate the exposed credential

If there is a realistic possibility that an API key escaped its intended security boundary, rotating it is generally safer than assuming every copy can be found and destroyed.

Google specifically recommends rotating API keys periodically and replacing compromised or unnecessarily exposed credentials.

A typical rotation process is:

1. create a replacement key;
2. apply appropriate restrictions;
3. update the legitimate application;
4. verify that the new credential works;
5. revoke or delete the old key.

Review usage before and after rotation

Provider logs, usage dashboards and billing data may help identify unexpected activity.

Look for:

• unusual request volumes;
• unexpected geographic sources;
• unexpected APIs;
• cost spikes;
• activity from old staging environments.

Rotation solves the continuing validity of the old credential. Monitoring helps determine whether the exposure was actually abused.

Settings exports, backups and migrations are different operations

A settings export should not be confused with a complete site backup.

A backup may legitimately contain sensitive application data because its purpose is to reproduce or recover the complete system.

That means backups require correspondingly stronger access control and retention policies.

A settings export has a narrower purpose.

It is intended to move selected configuration between WordPress installations.

For the full distinction, see Settings Export vs. Full Backup: What’s the Difference?.

Narrower scope should mean lower sensitivity

One of the advantages of a purpose-built settings export is that it can deliberately contain less sensitive information than a database or complete backup.

If the exporter simply dumps every available option, that advantage disappears.

Migrations need their own secret plan

When moving an entire WordPress site, think explicitly about:

• database credentials;
• API credentials;
• SMTP configuration;
• environment-specific URLs;
• payment integrations;
• webhooks;
• external service accounts.

Do not assume that every environment-specific value should be copied merely because the database is moving.

For related migration concerns, see How to Migrate WordPress URLs Safely and Why Serialized Data Breaks Naive WordPress Migrations.

How TheOneWP handles secrets in settings exports

TheOneWP’s Export Settings module is intentionally selective about what it makes portable.

Rather than treating every stored option as exportable configuration, the module uses an explicit set of option groups.

AI API keys are stripped before export

The verified implementation removes settings using the ai_ key prefix from the exported configuration before the archive is created.

This means AI credentials configured on the source site do not automatically travel inside the settings ZIP.

The destination can inherit the configuration while providing its own credential separately.

Runtime data is excluded too

The export also excludes data that does not belong to portable configuration, including specific runtime configuration and activity-related state.

This reinforces the distinction between:

• portable configuration;
• site-specific state;
• credentials;
• operational data.

The export is allowlisted rather than being a database dump

The module exports specific supported option groups instead of copying the entire WordPress options table.

That is important because a generic database dump and a configuration export solve different problems.

A configuration exporter should know what it intends to move.

Settings export security checklist

• Treat API keys as secrets, not ordinary plugin preferences.
• Do not automatically include secrets in portable settings exports.
• Use an allowlist of settings intended for export.
• Inspect nested option arrays for credentials before serialization.
• Keep production and staging credentials separate where practical.
• Do not reuse one client site’s private API credentials on another client site.
• Restrict API keys to only the APIs and environments that need them.
• Use separate credentials when separate environments need independent auditing or revocation.
• Do not assume encryption makes unnecessary secret export desirable.
• Provision or re-enter credentials separately after importing configuration.
• Protect any storage system that legitimately contains secrets.
• Keep exported configuration out of public repositories.
• Remember that deleted files may still exist in backups, email and shared storage.
• Rotate a key when you cannot confidently contain an exposure.
• Monitor API usage for suspicious activity.
• Delete unused credentials.
• Distinguish configuration exports from full backups.
• Review environment-specific settings during migrations.
• Do not assume every value in wp_options belongs in an export.
• Design portability and secret management as separate systems.

Related guides

• Settings Export vs. Full Backup: What’s the Difference?
• Standardizing WordPress Configuration Across Client Sites
• WordPress Staging Site Best Practices
• How to Migrate WordPress URLs Safely
• Why Serialized Data Breaks Naive WordPress Migrations
• WordPress File Permissions Explained
• WordPress REST API Security Basics
• WordPress Privacy and Third-Party Requests
• Path Traversal: What It Is and How Plugins Prevent It

Final recommendation

A settings export should make configuration portable without making credentials portable by accident.

The underlying rule is simple:

configuration describes what an application should do; a secret determines what the application is allowed to access.

Those concerns should remain separate.

If an API key is copied into every settings export, every export becomes another credential file that must be protected, tracked and eventually destroyed.

It can spread from production to staging, from one developer to another and, in agency workflows, potentially from one client environment to another.

A better architecture exports non-sensitive configuration and requires the destination environment to receive its credentials through a separate controlled process.

That makes environment separation easier, supports least privilege, improves auditability and limits the damage caused by a leaked export.

When a settings export genuinely does not need a secret, the safest way to protect that secret inside the export is not to encrypt it, rename it or hide it.

It is to leave it out.