Security Hardening
Security Hardening Protocols
To maintain the integrity of the WordPress environment and protect against common vulnerabilities such as Cross-Site Scripting (XSS) and SQL Injection, this project enforces strict data handling protocols. All developers contributing to or utilizing this codebase must adhere to the following sanitization, validation, and escaping standards.
1. Data Sanitization (Input)
Sanitization is the process of cleaning input data by stripping out unwanted characters. Always sanitize data before storing it in the database or using it in logic.
Use the following standard WordPress functions based on the data type:
| Function | Usage |
| :--- | :--- |
| sanitize_text_field() | Use for standard text inputs (strips tags/line breaks). |
| sanitize_email() | Use for email addresses. |
| sanitize_url() | Use for URLs. |
| absint() | Use for ensuring a value is a non-negative integer. |
| sanitize_textarea_field() | Use for multi-line text inputs while preserving line breaks. |
Example Usage:
// Handling a custom form submission
$user_bio = isset($_POST['bio']) ? sanitize_textarea_field($_POST['bio']) : '';
$user_age = isset($_POST['age']) ? absint($_POST['age']) : 0;
update_user_meta($user_id, 'bio', $user_bio);
2. Input Validation
Validation ensures that the data matches the expected format or constraints before any processing occurs. This should be performed alongside sanitization.
Nonce Verification
All state-changing actions (POST requests, deletions, updates) must be protected by nonces to prevent Cross-Site Request Forgery (CSRF).
// 1. Generate Nonce in a form
wp_nonce_field('update_settings_action', 'settings_nonce_field');
// 2. Verify Nonce on the processing side
if ( ! isset($_POST['settings_nonce_field']) || ! wp_verify_nonce($_POST['settings_nonce_field'], 'update_settings_action') ) {
wp_die('Security check failed');
}
Permission Checks
Always verify that the current user has the necessary capabilities to perform an action.
if ( ! current_user_can('manage_options') ) {
wp_die('You do not have sufficient permissions to access this page.');
}
3. Output Escaping (Late Escaping)
Escaping is the process of securing output data by stripping out unwanted HTML or scripts right before it is rendered in the browser. We follow the "Escape Late" principle: data should be escaped at the moment of echo, not before.
| Function | Usage |
| :--- | :--- |
| esc_html() | Use when a string contains HTML that should not be rendered. |
| esc_attr() | Use when outputting data into an HTML attribute (e.g., value=""). |
| esc_url() | Use for all URLs, including those in src or href attributes. |
| esc_js() | Use for inline Javascript strings. |
| wp_kses_post() | Use when you specifically need to allow safe HTML tags (like in post content). |
Example Usage:
<div class="user-profile">
<!-- Escaping HTML output -->
<h2><?php echo esc_html($user_name); ?></h2>
<!-- Escaping Attribute output -->
<input type="text" value="<?php echo esc_attr($stored_value); ?>" />
<!-- Escaping URLs -->
<a href="<?php echo esc_url($profile_link); ?>">View Profile</a>
</div>
4. Database Security
When performing custom queries, never pass raw variables into a query string. Use the $wpdb->prepare() method to prevent SQL injection.
Parameters:
query(string): The SQL query with placeholders (%sfor string,%dfor integer,%ffor float).args(mixed): The values to substitute into the placeholders.
Example Usage:
global $wpdb;
$user_id = 15;
$status = 'active';
$results = $wpdb->get_results(
$wpdb->prepare(
"SELECT * FROM {$wpdb->prefix}custom_table WHERE user_id = %d AND status = %s",
$user_id,
$status
)
);
Internal Security Utilities
While most operations utilize core WordPress functions, this repository may include internal helpers (prefixed with ua_) to streamline repetitive validation tasks.
ua_validate_config_payload(): (Internal) Validates internal JSON structures for MVP modules. Ensure your input arrays match the required schema defined in the module controller.