WordPress插件源码含敏感连接信息，如何安全隐藏至外部PHP文件？

Absolutely—moving sensitive credentials like MySQL/Azure connection strings out of your plugin’s publicly accessible code is a critical security step, and there are several robust, WordPress-aligned methods to implement this safely. Let’s walk through the best options:

1. Store Constants in wp-config.php (Quick & WordPress-Native) #

WordPress’s wp-config.php file is already designed to hold sensitive configuration data, and it’s not accessible via the built-in plugin editor (since it lives outside the wp-content/plugins directory).

• How to do it:
  Open your wp-config.php file (usually in your site’s root directory) and add your sensitive data as defined constants:

  // wp-config.php
  define('MY_PLUGIN_AZURE_CONN', 'DefaultEndpointsProtocol=https;AccountName=yourAccount;AccountKey=yourKey');
  define('MY_PLUGIN_DB_CONN', 'mysql:host=localhost;dbname=your_db;charset=utf8mb4');
  define('MY_PLUGIN_DB_USER', 'db_user');
  define('MY_PLUGIN_DB_PASS', 'db_password');
  

• In your plugin:
  Simply reference these constants directly—no need for extra includes:

  // Your plugin file
  $connectionString = MY_PLUGIN_AZURE_CONN;
  $db = new PDO(MY_PLUGIN_DB_CONN, MY_PLUGIN_DB_USER, MY_PLUGIN_DB_PASS);
  

• Pros: No extra files to manage, leverages WordPress’s existing secure file structure.
• Cons: Best for credentials shared across multiple plugins/themes; less ideal if you want plugin-specific isolation.

2. Use a Secure External File (Web Root Outside) #

For plugin-specific credentials, store them in a file outside your web server’s document root (so it can’t be accessed via a browser) and include it in your plugin.

• How to do it:
  1. Create a file (e.g., plugin-secrets.php) in a directory above your web root. For example, if your web root is /var/www/html, place the file at /var/www/secure-configs/plugin-secrets.php.
  2. Add your sensitive data to this file (use constants or variables—constants are safer to avoid variable collisions):

     // plugin-secrets.php
     define('MY_PLUGIN_AZURE_CONN', 'your-secure-connection-string');
     

  3. Set file permissions to 600 (Linux/macOS) so only the server user can read/write it.
• In your plugin:
  Include the file with an absolute path:

  // Your plugin file
  require_once('/var/www/secure-configs/plugin-secrets.php');
  $connectionString = MY_PLUGIN_AZURE_CONN;
  

• Pros: Complete isolation for plugin-specific data, fully inaccessible via web requests.
• Cons: Requires access to your server’s file system to place the file.

3. Environment Variables (Modern & DevOps-Friendly) #

Storing credentials as environment variables keeps them completely separate from your codebase, making deployment, CI/CD, and credential rotation much easier.

• How to set them:
  • Apache: Add to your .htaccess file (ensure .htaccess is not publicly accessible):

    SetEnv MY_PLUGIN_AZURE_CONN "your-secure-string"
    

  • Nginx: Add to your server block configuration:

    fastcgi_param MY_PLUGIN_AZURE_CONN "your-secure-string";
    

  • Server-wide: Use your server’s environment variable system (e.g., /etc/environment on Linux) or a .env file (place it outside the web root, set permissions to 600).
• In your plugin:
  Retrieve the variable using PHP’s getenv() function:

  // Your plugin file
  $connectionString = getenv('MY_PLUGIN_AZURE_CONN');
  

• Pros: Credentials never touch your code, easy to manage across environments, perfect for version control (no sensitive data in Git).
• Cons: Requires server configuration access.

4. Encrypted WordPress Options (For Database-Stored Credentials) #

If you need to manage credentials via the WordPress admin (e.g., a settings page), store them encrypted in the WordPress database using the Options API.

• How to do it:
  1. Define an encryption key in wp-config.php:

     define('MY_PLUGIN_ENCRYPT_KEY', 'your-strong-random-key-here');
     

  2. Use WordPress’s built-in wp_encrypt() and wp_decrypt() functions to handle encryption:

     // Save credentials (e.g., in a settings page)
     $encrypted_conn = wp_encrypt('your-azure-string', MY_PLUGIN_ENCRYPT_KEY);
     update_option('my_plugin_azure_conn', $encrypted_conn);
     
     // Retrieve in your plugin
     $encrypted_conn = get_option('my_plugin_azure_conn');
     $connectionString = wp_decrypt($encrypted_conn, MY_PLUGIN_ENCRYPT_KEY);
     

• Pros: Allows admin-managed credentials, encrypted at rest in the database.
• Cons: Adds extra complexity; encryption key still needs to be stored securely (e.g., in wp-config.php).

Critical Security Notes #

• File Permissions: Always set configuration files to 600 (read/write only for the owner) to prevent unauthorized access.
• Version Control: Add any external config files (like .env or plugin-secrets.php) to your .gitignore to avoid committing sensitive data to your repository.
• Restrict Plugin Editor Access: Ensure only trusted admins have access to the WordPress plugin editor (WordPress defaults to this, but you can enforce it with plugins or custom code if needed).
• Avoid Debug Output: Never print or log sensitive credentials, even during debugging.

For most use cases, environment variables or web-root-external config files are the best balance of security and maintainability.

内容的提问来源于stack exchange，提问作者jdoe