¿Cuál es el propósito de `$wpdb->prepare()` y cómo impide las inyecciones SQL?

`$wpdb->prepare()` gestiona la parametrización de consultas SQL. Recibe una plantilla con especificadores de formato (`%d`, `%f`, `%s`, `%i`) y los argumentos correspondientes. Fuerza la conversión de los parámetros numéricos a `int` y `float`, mientras que a las cadenas les aplica escape y las envuelve entre comillas, garantizando que los datos no puedan alterar la estructura sintáctica de la consulta.

¿Cuáles son las diferencias de comportamiento entre `$wpdb->get_var()`, `$wpdb->get_row()` y `$wpdb->get_results()`?

`$wpdb->get_var()` extrae una única celda escalar (como el resultado de `COUNT(*)`); `$wpdb->get_row()` retorna una única fila en formato de objeto o array asociativo; `$wpdb->get_results()` devuelve el conjunto completo de filas resultante de la selección.

¿Por qué `esc_sql()` por sí sola no garantiza inmunidad frente a inyecciones SQL?

`esc_sql()` se limita a escapar caracteres de control sin entrecomillar la cadena resultante. Si se concatena en un entorno numérico (`WHERE id = ' . esc_sql($id)`), un atacante puede transmitir `0 OR 1=1` sin activar ningún escape, ejecutando código arbitrario. La inmunidad requiere parametrización tipada con `%d` mediante `$wpdb->prepare()`.

¿Cómo opera el marcador `%i` en `$wpdb->prepare()` (introducido en WordPress 6.2)?

El marcador `%i` gestiona identificadores dinámicos de tablas y columnas. A diferencia de `%s` (que entrecomilla el texto con apóstrofos simples `'table'`, quebrando la sintaxis SQL), `%i` suprime tildes invertidas y envuelve el nombre en comillas de identificador (`` `wp_posts` ``), permitiendo ordenar por columnas dinámicas de forma segura.

¿Por qué es obligatorio usar `$wpdb->esc_like()` antes de evaluar cláusulas LIKE?

Los caracteres `%` y `_` operan como comodines sintácticos en SQL. Si un usuario ingresa `%` en un formulario de búsqueda sin `esc_like()`, la consulta se transformará en `LIKE '%%%'`, forzando a MySQL a realizar un Full Table Scan. `$wpdb->esc_like()` antepone barras invertidas (`\%`), convirtiéndolos en caracteres literales inofensivos.

¿Por qué no se puede suministrar directamente un array a un marcador `IN (...)` en `$wpdb->prepare()` y cómo se subsana?

Asignar un array a `%s` lo transforma en una única cadena literal `'1,2,3'`, resultando en `IN ('1,2,3')` en lugar de `IN (1, 2, 3)`. La solución consiste en generar dinámicamente la secuencia de marcadores: `$placeholders = implode(',', array_fill(0, count($ids), '%d'))`, incrustarla en la plantilla y desempaquetar el array mediante el operador de propagación: `$wpdb->prepare("... IN ({$placeholders})", ...$ids)`.

¿Cómo se gestiona adecuadamente una transacción en `$wpdb` para operaciones financieras o de inventario interdependientes?

Invocando directamente sentencias InnoDB: 1) `$wpdb->query('START TRANSACTION');`; 2) Ejecutar las mutaciones dentro de un bloque `try`; 3) En caso de éxito, ejecutar `$wpdb->query('COMMIT');`; 4) En el bloque `catch (\Throwable $e)`, invocar obligatoriamente `$wpdb->query('ROLLBACK');` y registrar el error en la infraestructura de auditoría.

¿Cómo se previene la inyección SQL en ordenaciones dinámicas `ORDER BY $column $direction`?

Mediante una lista blanca inmutable: 1) Comprobar las columnas autorizadas con `in_array($orderBy, ['id', 'date', 'price'], true)`; 2) Forzar la normalización del sentido: `$orderDir = strtoupper($dir) === 'DESC' ? 'DESC' : 'ASC';`; 3) Interpolar el identificador con `%i`: `$wpdb->prepare('ORDER BY %i ' . $orderDir, $orderBy)`.

¿Cómo se automatiza el análisis estático para detectar vulnerabilidades en `$wpdb` dentro de una canalización CI/CD empresarial?

Implementando dos barreras de calidad: 1) `PHP_CodeSniffer` con las reglas `WordPress.DB.PreparedSQL` y `WordPress.DB.PreparedSQLPlaceholders`, que bloquean cualquier concatenación en `$wpdb->query()` o desfase en los argumentos de `prepare()`; 2) El analizador `PHPStan` con la extensión `szepeviktor/phpstan-wordpress` configurada en nivel de rigor 8 o 9.

¿Cómo se previenen los bloqueos mutuos (Deadlocks) en MySQL ante ráfagas concurrentes de UPDATE/INSERT con $wpdb?

1) Actualizando los registros siempre en un orden determinista predecible (por ejemplo, ordenando los IDs de menor a mayor antes de iniciar la transacción); 2) Reduciendo al mínimo la ventana de retención de bloqueos (efectuando cálculos antes de invocar `START TRANSACTION`); 3) Ajustando los niveles de aislamiento (`READ COMMITTED` en lugar de `REPEATABLE READ` cuando sea viable); 4) Implementando un mecanismo de reintento con backoff exponencial al detectar el error 1213 de MySQL.

Defensa contra inyecciones SQL y seguridad de bajo nivel con $wpdb — WordPress Fullstack

title: Defensa contra inyecciones SQL y seguridad de bajo nivel con $wpdb description: >- Análisis exhaustivo de seguridad de base de datos en WordPress 7.0+ (PHP 8.4+): funcionamiento interno de $wpdb->prepare(), el marcador de identificadores %i (WP 6.2+), búsquedas LIKE seguras mediante esc_like, transacciones InnoDB y por qué esc_sql() sin comillas constituye una vulnerabilidad crítica. module: security order: 2 difficulty: advanced estimatedTime: 42 min topics:

WordPress Security
$wpdb
SQL Injection
'wpdb::prepare'
'%i Placeholder'
InnoDB Transactions
PHP 8.4 prerequisites:
wp-architecture
wp-query-mastery
nonce-sanitize-escape id: wpdb-injection duration: 42 xp: 45 tags:
wordpress-security
wpdb
sql-injection
wpdb-prepare
i-placeholder
innodb-transactions
php-8-4

Base arquitectónica#

La inyección SQL (SQLi, CWE-89) continúa siendo una de las categorías de vulnerabilidad más devastadoras en la ingeniería de software web. Su explotación exitosa permite al atacante eludir las reglas de negocio, exfiltrar registros confidenciales de usuarios, sobrescribir hashes de contraseñas de administradores en wp_users, implantar puertas traseras persistentes o destruir por completo los clústeres de bases de datos.

En el núcleo de WordPress, la comunicación con el motor de base de datos está encapsulada en la clase singleton global $wpdb (una instancia de wpdb). La concatenación directa de variables procedentes de usuarios en sentencias SQL sin procesar está estrictamente prohibida. El estándar indiscutible de ejecución segura es la Parametrización mediante el método $wpdb->prepare().

No obstante, muchos desarrolladores introducen fallas arquitectónicas severas debido a conceptos erróneos habituales:

Confianza ciega en esc_sql(): La función esc_sql() únicamente neutraliza caracteres especiales en literales de texto, pero no envuelve los valores entre comillas. Si una variable se concatena en una cláusula numérica (WHERE id = $id), el atacante puede inyectar 1 OR 1=1 y la inyección se ejecutará con éxito, puesto que no contiene caracteres especiales que escapar.
Interpolación errónea de nombres de tablas y columnas: El marcador %s rodea automáticamente el valor con comillas simples (SELECT * FROM 'wp_posts'), generando un error de sintaxis en MySQL. En WordPress moderno, la interpolación segura de identificadores dinámicos se realiza mediante el marcador especializado %i (Identifier Placeholder).
Ataques de denegación de servicio (DoS) mediante cláusulas LIKE: Construcciones de búsqueda como LIKE '%term%' sin invocar previamente $wpdb->esc_like() permiten a un atacante enviar comodines % y _, degradando la consulta a un costoso Full Table Scan que satura la CPU del servidor.

Modelo mental#

Imagine la ejecución de consultas SQL mediante $wpdb->prepare() como la firma de un contrato formal ante un notario público:

Plantilla de consulta con marcadores (%d, %f, %s, %i) es el formulario preimpreso oficial con campos en blanco fuertemente tipados (en el campo de "Importe" %d físicamente solo caben enteros numéricos, en el campo de "Nombre" %s se escribe texto entrecomillado, y en el de "Unidad Organizativa" %i solo se acepta un identificador certificado).
El método $wpdb->prepare() es el notario que revisa la documentación e inscribe personalmente los valores, asegurando que las cadenas queden blindadas entre comillas y que los números se reduzcan a sus primitivas matemáticas.
La concatenación directa ("WHERE id = " . $_GET['id']) equivale a firmar una hoja en blanco, permitiendo a la contraparte redactar cláusulas arbitrarias en letra pequeña («...y traspasar todas las propiedades de la empresa a mi favor: OR 1=1; DROP TABLE wp_users;»).

code

DATOS ENTRANTES: $_POST['status'], $_POST['limit'], $_POST['table']
                                │
                                ▼
┌────────────────────────────────────────────────────────────────────────┐
│ PLANTILLA: "SELECT * FROM %i WHERE status = %s LIMIT %d"               │
└──────────────────────────────┬─────────────────────────────────────────┘
                               │ Invocación de $wpdb->prepare(..., $table, $status, $limit)
                               ▼
┌────────────────────────────────────────────────────────────────────────┐
│ CANALIZACIÓN DE PROCESAMIENTO:                                         │
│ • %i (Identificador) ──► Envoltorio en tildes invertidas: `wp_table`   │
│ • %s (Cadena)        ──► mysqli_real_escape_string + comillas simples  │
│ • %d (Entero)        ──► Coerción forzada con intval()                 │
└──────────────────────────────┬─────────────────────────────────────────┘
                               │ SQL resultante seguro
                               ▼
┌────────────────────────────────────────────────────────────────────────┐
│ EJECUCIÓN EN MYSQL: $wpdb->get_results()                               │
│ SELECT * FROM `wp_custom_table` WHERE status = 'active' LIMIT 20;      │
└────────────────────────────────────────────────────────────────────────┘

Canalización de arquitectura

Ciclo de vida de preparación y ejecución segura de consultas en $wpdb

5 etapas

1. Template Definition with Specifiers

Núcleo / Sistema

La consulta se formula con marcadores explícitos: %d (enteros), %f (flotantes), %s (cadenas) y %i (identificadores de tablas/columnas).

2. Placeholder Matching & Type Casting

Núcleo / Sistema

El método prepare() emplea rutinas vsprintf() para imponer coerción numérica estricta (intval/floatval) y valida el recuento de argumentos.

3. String Escaping & Quoting

Núcleo / Sistema

Para marcadores %s, los caracteres especiales (, , , , ', ", ) se escapan y el valor se envuelve entre comillas simples.

4. Identifier Quoting (%i)

Núcleo / Sistema

Para marcadores %i, los valores se depuran de tildes invertidas y se encierran en apóstrofos de identificador (`table_name`).

5. Transaction Execution & Error Handling

Núcleo / Sistema

La consulta se envía al motor con soporte de transacciones ACID (START TRANSACTION, COMMIT, ROLLBACK) y monitorización de errores.

5 términos fundamentales#

Aplicación práctica#

En la arquitectura de Fullstack Agentic Lab, los estándares de seguridad de $wpdb se implementan para:

Repositorios de datos de alto rendimiento (Custom Tables): Diseño y consulta segura en tablas dedicadas de telemetría, eventos de auditoría y matrices de competencias.
Mitigación total de Blind SQL Injection: Supresión absoluta de concatenaciones en cláusulas WHERE, ORDER BY y GROUP BY.
Flujos transaccionales resilientes en e-commerce: Asignación atómica de inventario y pedidos procesados bajo transacciones InnoDB.
Búsqueda facetada segura: Escape de términos de búsqueda mediante $wpdb->esc_like() antes de la asignación de parámetros con %s.

Cómo funciona#

Contraste entre patrones vulnerables y el estándar endurecido de $wpdb:

Patrones vulnerables de $wpdb frente al estándar seguro

Критерий	Código vulnerable (Riesgo crítico de SQLi)	Estándar 2026: $wpdb->prepare() endurecido
Filtro numérico en WHERE	$wpdb->query("WHERE id = " . $_GET['id']) (Inyección ciega crítica)	$wpdb->prepare('WHERE id = %d', $id) — coerción forzada a intval
Nombre de tabla dinámico	$wpdb->query("SELECT * FROM " . $_POST['table'])	$wpdb->prepare('SELECT * FROM %i', $table) con lista blanca estricta
Búsqueda por coincidencia (LIKE)	$wpdb->prepare('WHERE title LIKE %s', '%' . $term . '%') (Riesgo DoS)	$wpdb->prepare('WHERE title LIKE %s', '%' . $wpdb->esc_like($term) . '%')
Uso de esc_sql() sin comillas	$wpdb->query("WHERE status = " . esc_sql($status)) (Inyección factible)	$wpdb->prepare('WHERE status = %s', $status) con entrecomillado automático
Integridad multiconsulta ante fallos	Múltiples llamadas a $wpdb->insert() sin transacciones (datos corruptos)	Encapsulamiento en START TRANSACTION ... COMMIT con captura y ROLLBACK

A continuación se presenta un artefacto de producción desarrollado para WordPress 7.0+ y PHP 8.4+. Implementa un Enterprise Audit Telemetry Repository con:

Parametrización estricta de todos los tipos escalares (%d, %s, %f).
Interpolación de identificadores con %i y validación secundaria contra una lista blanca inmutable.
Neutralización de comodines mediante $wpdb->esc_like().
Atomicidad transaccional con InnoDB y reversión ante excepciones.

Production ArtifactRepositorio de telemetría empresarial en $wpdb con defensa SQLi y transacciones (PHP 8.4+)

Repositorio de base de datos industrial: parametrización %d, %s, %i, búsqueda LIKE segura, transacciones InnoDB y paginación Keyset.

<?php
/**
* Plugin Name: Fullstack Agentic Lab — Enterprise Database Repository
* Description: Arquitectura segura con $wpdb: marcador %i, transacciones InnoDB y prevención de SQLi.
* Version:     3.0.0
* Requires at least: 6.8
* Requires PHP: 8.4
* Author:      Artur Yusupov (Fullstack Agentic Lab)
*/

declare(strict_types=1);

namespace AgenticLab\Security\Database;

use RuntimeException;
use wpdb;

defined('ABSPATH') || exit;

final readonly class TelemetryLogRepository
{
  /**
   * Lista blanca de tablas autorizadas para evitar sustituciones maliciosas de esquemas.
   */
  private const array ALLOWED_TABLES = [
      'agentic_telemetry_logs',
      'agentic_audit_events',
      'agentic_performance_benchmarks',
  ];

  public function __construct(
      private wpdb $db
  ) {}

  /**
   * Registra un evento de auditoría dentro de una transacción InnoDB segura.
   *
   * @param array{userId: int, eventName: string, latencyMs: float, payload: array<string, mixed>} $eventData
   */
  public function recordEvent(string $tableName, array $eventData): int
  {
      $sanitizedTable = $this->assertValidTable($tableName);

      // Iniciar transacción para garantizar atomicidad ACID
      $this->db->query('START TRANSACTION');

      try {
          $fullTableName = $this->db->prefix . $sanitizedTable;

          // CRÍTICO: ¡Usar %i (WP 6.2+) para nombres de tablas!
          // Parámetros escalares: %d (enteros), %s (cadenas), %f (flotantes)
          $query = $this->db->prepare(
              'INSERT INTO %i (user_id, event_name, latency_ms, payload_json, created_at_gmt)
               VALUES (%d, %s, %f, %s, %s)',
              $fullTableName,
              $eventData['userId'],
              $eventData['eventName'],
              $eventData['latencyMs'],
              wp_json_encode($eventData['payload'], JSON_UNESCAPED_SLASHES | JSON_UNESCAPED_UNICODE),
              gmdate('Y-m-d H:i:s')
          );

          $result = $this->db->query($query);

          if ($result === false) {
              throw new RuntimeException("Error en la ejecución de SQL: {$this->db->last_error}");
          }

          $insertedId = (int) $this->db->insert_id;

          // Confirmar transacción
          $this->db->query('COMMIT');

          return $insertedId;
      } catch (\Throwable $e) {
          // Revertir inmediatamente ante cualquier error
          $this->db->query('ROLLBACK');
          throw new RuntimeException("Transacción revertida: {$e->getMessage()}", 0, $e);
      }
  }

  /**
   * Búsqueda por coincidencia de subcadena con escape seguro de LIKE y paginación Keyset.
   *
   * @return array<int, array<string, mixed>>
   */
  public function searchEvents(
      string $tableName,
      string $searchTerm,
      int $minUserId,
      int $lastSeenId = 0,
      int $limit = 50
  ): array {
      $sanitizedTable = $this->assertValidTable($tableName);
      $fullTableName  = $this->db->prefix . $sanitizedTable;

      // 1. CRÍTICO: ¡Escapar comodines de LIKE (% y _) antes de la interpolación!
      $escapedSearch = $this->db->esc_like($searchTerm);
      $likeArgument  = '%' . $escapedSearch . '%';

      // 2. Paginación Keyset basada en cursor en lugar de LIMIT offset
      $query = $this->db->prepare(
          'SELECT id, user_id, event_name, latency_ms, created_at_gmt
           FROM %i
           WHERE event_name LIKE %s
             AND user_id >= %d
             AND id > %d
           ORDER BY id ASC
           LIMIT %d',
          $fullTableName,
          $likeArgument,
          $minUserId,
          $lastSeenId,
          min($limit, 100)
      );

      /** @var array<int, array<string, mixed>>|null $results */
      $results = $this->db->get_results($query, ARRAY_A);

      return $results ?: [];
  }

  /**
   * Valida nombres dinámicos de tablas contra una lista blanca inmutable.
   */
  private function assertValidTable(string $table): string
  {
      $clean = sanitize_key($table);
      if (!in_array($clean, self::ALLOWED_TABLES, true)) {
          throw new RuntimeException("Intento de acceso a tabla no autorizada: {$table}");
      }

      return $clean;
  }
}

Errores comunes#

Ошибка: Pasar cadenas ya concatenadas al método $wpdb->prepare()

Ошибка: Utilizar el marcador %s para nombres de tablas o columnas

Ошибка: Ejecutar consultas LIKE sin invocar $wpdb->esc_like()

Ошибка: Confiar en esc_sql() para valores numéricos sin envolver en comillas

Algoritmo paso a paso para diseñar consultas seguras#

Cuatro fases hacia una consulta invulnerable en $wpdb

Paso 1: Diseño de plantilla con tipos de marcadores explícitos

Mapee cada variable a su formato exacto: %d para IDs y contadores, %f para importes, %s para cadenas y %i para identificadores.

Paso 2: Validación de identificadores por lista blanca

Si las tablas o columnas son dinámicas, verifique que pertenezcan a una matriz inmutable definida en constantes.

Paso 3: Neutralización de comodines con esc_like()

En cláusulas LIKE, procese el texto con $wpdb->esc_like() antes de incorporar los porcentajes de búsqueda.

Paso 4: Ejecución transaccional y gestión de excepciones

Agrupe mutaciones en bloques START TRANSACTION / COMMIT, inspeccione $wpdb->last_error y aplique ROLLBACK ante fallos.

Preguntas de entrevista técnica (Junior → Lead)#

Preguntas de entrevista10 preguntas

Temas relacionados#

Temas relacionados

Seguridad del núcleo: Nonces, Sanitization, Late Escaping y filtrado con wp_kses— Primera lección del módulo: la tríada de seguridad y prevención de CSRF.Prevención de XSS, CSRF y encabezados modernos CSP— Siguiente lección: aseguramiento del perímetro en el cliente frente a scripts de terceros.WP_Query a nivel Senior: Indexación SQL y ganchos de filtro internos— Cómo construye el núcleo de WordPress consultas SQL parametrizadas dentro de WP_Query.