How to Securely Store API Credentials in WordPress

API credentials are the keys to your data kingdom. Here is how to store them securely in WordPress.

Why credential security matters

Every WordPress site that connects to external APIs stores credentials: API keys, OAuth tokens, passwords, and client secrets. These credentials grant access to your data and the data of your users. If they are exposed, attackers can impersonate your site, access sensitive data, or cause financial damage.

Most WordPress plugins store API credentials in the WordPress options table in plaintext. This means:

• Anyone with database access can read your credentials
• Database backups contain your credentials in plaintext
• If your database is leaked, your credentials are exposed
• Staging site copies may retain production credentials

Ingestics takes a different approach: all credentials are encrypted with AES-256-CBC before storage.

How Ingestics stores credentials

AES-256-CBC encryption

Ingestics uses AES-256-CBC (Advanced Encryption Standard, 256-bit key, Cipher Block Chaining) to encrypt all API credentials before storing them in the database. AES-256 is the same encryption standard used by banks, governments, and the US military.

The encryption process works as follows:

1. When you enter an API key, password, or token in Ingestics, it is immediately encrypted in memory
2. The encrypted value is stored in the WordPress options table
3. When Ingestics needs to use the credential (e.g., to fetch from an API), it decrypts the value in memory
4. The decrypted value is used for the API request and then discarded
5. The decrypted value is never written to the database, logs, or any persistent storage

Encryption key management

The encryption key is derived from WordPress’s AUTH_KEY and AUTH_SALT constants in wp-config.php. These are unique to your site and should never be shared. If you change your wp-config.php keys, all stored credentials will need to be re-entered.

What gets encrypted

Ingestics encrypts all sensitive fields:

• API keys (query parameter and header types)
• Bearer tokens
• Basic Auth passwords
• OAuth2 client secrets
• OAuth2 refresh tokens
• OpenAI API keys
• Anthropic API keys
• Google Gemini API keys
• DeepL API keys
• AWS access key secret
• Any custom header values marked as sensitive

SSRF protection

Server-Side Request Forgery (SSRF) is a vulnerability where an attacker tricks a server into making requests to internal network addresses. In a WordPress context, this could allow an untrusted user to make your server fetch data from internal services (e.g., http://localhost:8080/admin or http://169.254.169.254/latest/meta-data/ on AWS).

Ingestics includes SSRF protection that blocks requests to:

• Private IP ranges (10.x.x.x, 172.16.x.x-172.31.x.x, 192.168.x.x)
• Loopback addresses (127.x.x.x, ::1)
• Link-local addresses (169.254.x.x)
• Cloud metadata endpoints (169.254.169.254)
• Any hostname that resolves to a private IP address

SSRF protection is always enabled and cannot be disabled. This ensures that even if an untrusted user gains access to the Ingestics admin interface, they cannot use it to probe your internal network.

Diagnostic masking

When Ingestics logs diagnostic information (e.g., failed API requests, error messages), all sensitive data is masked. The log shows:

• Authorization: Bearer *** instead of the actual token
• X-API-Key: *** instead of the actual key
• password=*** instead of the actual password

This ensures that log files, error reports, and diagnostic screens do not expose credentials even to administrators who have access to the logs.

Nonce verification

All Ingestics admin actions (save, delete, fetch, test, import, export) require WordPress nonces. A nonce is a one-time-use token that prevents Cross-Site Request Forgery (CSRF) attacks. Without a valid nonce, Ingestics will not perform any action.

This means that even if an attacker tricks an administrator into visiting a malicious URL, Ingestics will not perform any action unless the URL includes a valid nonce that the attacker cannot generate.

Config portability and credential redaction

When you export your Ingestics configuration (Pro+), all credentials are redacted. The export file contains the provider configuration, field mappings, templates, and settings — but not the actual credentials.

This is important for:

• Staging/production sync — Export from production, import to staging. Staging will have the same configuration but no credentials. You enter them manually on staging.
• Sharing configs with team members — Share the export file without exposing credentials
• Backup — Your backup file does not contain credentials, so even if it is leaked, your APIs are safe
• Version control — You can commit the export file to git without leaking secrets

Best practices for API credential security in WordPress

1. Use encrypted storage

Never store API credentials in the WordPress options table in plaintext. Use a plugin like Ingestics that encrypts credentials with AES-256 before storage. If you are writing custom code, use openssl_encrypt() with a key derived from wp-config.php constants.

2. Rotate credentials regularly

Change your API keys and tokens every 3-6 months. Most API providers allow you to generate new keys and revoke old ones. If a credential is compromised, rotate it immediately and update it in Ingestics.

3. Use the principle of least privilege

When creating API keys on external services, grant only the permissions you need. If you only need read access, create a key with read-only permissions. Do not use keys with write or admin access for fetching data.

4. Enable SSRF protection

If you are using a plugin that fetches data from URLs, ensure SSRF protection is enabled. Ingestics enables it by default, but many other plugins do not. Without SSRF protection, an attacker could use your site to scan internal networks or access cloud metadata.

5. Audit your wp-config.php keys

WordPress generates unique AUTH_KEY and AUTH_SALT values during installation. If you copied your wp-config.php from a tutorial or another site, regenerate these keys. Use the WordPress secret key generator to generate new values.

6. Protect your database

Even with encrypted credentials, your database should be protected:

• Use a strong database password
• Restrict database access to localhost only
• Use a dedicated database user with limited permissions (not root)
• Encrypt database backups at rest
• Never commit database dumps to version control

7. Use HTTPS for API requests

Ingestics always uses HTTPS for API requests when the endpoint supports it. Never configure an API provider with an HTTP (non-HTTPS) URL for sensitive data. HTTP traffic can be intercepted by anyone on the network path.

8. Monitor for credential leaks

Regularly check for unexpected API usage, unauthorized requests, or unusual activity on your API provider accounts. Most API providers offer usage analytics and alerting for suspicious activity.

How Ingestics compares to other plugins

Most WordPress API and RSS plugins do not encrypt credentials. Here is how Ingestics compares:

Getting started

Ingestics includes all security features on every plan, including the free edition. Install it from WordPress.org, create an API or RSS provider, and enter your credentials with confidence that they are encrypted and protected.

Learn more about Ingestics security features →