Encrypted Credential Storage for WordPress APIs – Ingestics
AES-256-CBC Encryption via OpenSSL
All credentials in Ingestics – API keys, passwords, tokens – are encrypted at rest using AES-256-CBC via PHP’s OpenSSL extension. Credentials are never stored in plaintext in the database. The encryption is applied at the storage layer, so even if the database is compromised, the credentials remain encrypted without the WordPress secret keys.
Key Derivation from WordPress AUTH_KEY and AUTH_SALT
The encryption key is derived from your WordPress AUTH_KEY and AUTH_SALT constants defined in wp-config.php. These constants are unique to your installation and are not stored in the database. Because the key is derived from configuration constants rather than stored alongside the data, an attacker who gains database access alone cannot decrypt your credentials.
SSRF Protection
Ingestics includes Server-Side Request Forgery (SSRF) protection that blocks requests to internal IP ranges. When a provider URL resolves to a private or loopback address – such as 10.x.x.x, 172.16.x.x, 192.168.x.x, or 127.x.x.x – the request is blocked. This prevents a malicious or compromised provider configuration from accessing internal network services.
Diagnostic Masking
When Ingestics logs diagnostic information – such as API request headers, response bodies, or error messages – all API keys and credentials are replaced with asterisks. This ensures that sensitive data never appears in log files, error messages, or diagnostic screens, even when detailed logging is enabled for troubleshooting.
Automatic Fetch-Log Retention
Fetch logs accumulate over time as providers fetch new content. Ingestics automatically cleans up old log entries on a configurable retention schedule. This prevents the log table from growing unbounded and keeps your database lean. The retention period is adjustable, so you can balance diagnostic visibility against database size.
Security Features
| Feature | Description | Scope |
|---|---|---|
| AES-256-CBC encryption | Credentials encrypted at rest via OpenSSL | All stored credentials |
| Key derivation | Encryption key from AUTH_KEY and AUTH_SALT | Per-installation |
| SSRF protection | Blocks requests to internal/private IP ranges | All provider URLs |
| Diagnostic masking | API keys replaced with asterisks in logs and errors | All log output |
| Fetch-log retention | Automatic cleanup of old log entries | Configurable retention period |
Tier Availability
| Tier | Security Features |
|---|---|
| Free | Full – encryption, SSRF protection, diagnostic masking, log retention |
| Lite | Full – all security features |
| Pro | Full – all security features |
| Business | Full – all security features |
Frequently Asked Questions
How are API keys stored in the database?
API keys and all other credentials are encrypted using AES-256-CBC via PHP’s OpenSSL extension before being written to the database. The encryption key is derived from your WordPress AUTH_KEY and AUTH_SALT constants, which are defined in wp-config.php and are unique to your installation.
What does SSRF protection do?
SSRF protection blocks API and RSS requests that resolve to internal or private IP addresses (such as 10.x.x.x, 192.168.x.x, or 127.x.x.x). This prevents a compromised provider configuration from being used to access services on your internal network.
Do API keys appear in logs?
No. All diagnostic output – logs, error messages, and diagnostic screens – masks credentials by replacing them with asterisks. Even with detailed logging enabled, your API keys and passwords are never written to log files.
Start automating.
Download Ingestics free. Start fetching APIs and RSS feeds in minutes.