Init Sentinel – Part 1: Creating a Database for Tracking Unauthorized Access in WordPress

The goal is not to log everything, but to log the right data, enabling meaningful analysis, monitoring, and security responses later.

The Database Design Philosophy Behind Init Sentinel

Init Sentinel is designed around three core principles that balance security, performance, and long-term maintainability.

• Silent: Logging must not impact frontend performance or user experience.
• Minimal PII: Only store data that is necessary for security analysis.
• Actionable: Logs must be useful for detecting abnormal behavior.

This approach keeps the system compliant, lightweight, and powerful enough to support advanced security layers.

Structure of the init_sentinel_security_log Table

The Init Sentinel log table is designed to provide sufficient context for analysis while remaining efficient under real-world traffic.

• id: Primary key with auto-increment.
• user_id: WordPress user ID, if the request is authenticated.
• ip_address: Client IP address, supporting both IPv4 and IPv6.
• endpoint: The accessed endpoint or URL.
• action: The recorded security action or event type.
• status_code: HTTP status code, with special focus on 403 responses.
• user_agent: User-Agent string for basic bot identification.
• created_at: Timestamp of when the event occurred.

Indexes are intentionally added to support common queries such as filtering by IP address, user ID, or time range without causing full table scans.

Database Creation Function for Init Sentinel

The following core function, using the init_html_* prefix, is responsible for creating the security log table for the Init Sentinel module.

// Create security log table (silent, minimal PII)
function init_html_create_security_log_table() {
    global $wpdb;
    $table = $wpdb->prefix . 'init_sentinel_security_log';
    $charset_collate = $wpdb->get_charset_collate();

    $sql = "
        CREATE TABLE {$table} (
            id BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT,
            user_id BIGINT(20) UNSIGNED DEFAULT NULL,
            ip_address VARCHAR(45) NOT NULL,
            endpoint VARCHAR(255) NOT NULL,
            action VARCHAR(100) NOT NULL,
            status_code INT(3) NOT NULL,
            user_agent TEXT,
            created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
            PRIMARY KEY (id),
            KEY user_id (user_id),
            KEY ip_address (ip_address),
            KEY created_at (created_at)
        ) {$charset_collate};
    ";

    require_once ABSPATH . 'wp-admin/includes/upgrade.php';
    dbDelta($sql);
}

Why Init Sentinel Uses dbDelta

Instead of executing raw SQL directly, Init Sentinel relies on dbDelta to ensure safe schema evolution over time.

• Automatically handles schema changes without data loss.
• Supports incremental updates across versions.
• Reduces deployment risk across environments.

This makes Init Sentinel a long-term security layer rather than a disposable logging feature.

Important Deployment Considerations

When using this log table in a production environment, several operational rules should be followed.

• Do not log every request, only suspicious or denied access.
• Avoid storing request payloads or form data.
• Implement log rotation or cleanup strategies.

A well-designed database does not create security by itself, but without it, security cannot be measured or controlled.

Conclusion

With this database structure in place, Init Sentinel gains a solid foundation for tracking and analyzing unauthorized access in WordPress.

In the next article, we will focus on the core logging function of Init Sentinel, where security data begins to deliver real value.