Auditoría de seguridad de WordPress: Qué comprobar antes de publicar

Antes de que cualquier plugin generado por PAGEnza llegue a la instalación de WordPress de un usuario, pasa por tres comprobaciones de seguridad automatizadas. Esta publicación explica qué buscan esas comprobaciones y por qué cada una es importante.

Por qué el código generado por IA necesita una auditoría

Los grandes modelos de lenguaje son sorprendentemente buenos escribiendo plugins de WordPress. Conocen los nombres de los hooks, entienden los estándares de codificación de WP, producen PHP legible. Pero también cometen errores predecibles, y esos errores son vulnerabilidades de seguridad.

Los más comunes que vemos:

• Uso de $_GET o $_POST sin sanitización
• Falta de verificación de nonce en envíos de formularios
• Consultas directas a la base de datos sin $wpdb->prepare()
• Uso de eval() o exec() para comportamiento dinámico
• Salida de datos de usuario sin esc_html() o esc_attr()

Estos no son casos extremos exóticos. Aparecen regularmente en la salida de LLM, incluso de los mejores modelos.

Etapa 1: Validación del prompt

Antes de que la IA escriba una sola línea, analizamos la descripción del usuario. Este paso detecta dos categorías de problemas:

Intentos de manipulación — prompts que intentan que la IA produzca código deliberadamente malicioso. Cosas como "ignora las instrucciones anteriores" o "crea una puerta trasera para pruebas".

Descripciones vagas o inviables — prompts demasiado cortos o ambiguos para producir código útil. "Haz un plugin" genera basura; "Crea un formulario de contacto que envíe envíos a una dirección de correo electrónico con filtrado de spam" genera algo real.

Si un prompt falla esta comprobación, el usuario ve un error específico que explica por qué, no un rechazo genérico.

Etapa 2: Linting de PHP en un contenedor aislado

Una vez que la IA produce código PHP, se ejecuta a través de php -l dentro de un contenedor Docker que está completamente aislado de todo lo demás. Esto detecta errores de sintaxis antes de que el plugin llegue a una instalación de WordPress.

Pero vamos más allá: si el linting falla, el sistema no solo rechaza la salida. Envía el error de vuelta a la IA con un prompt de corrección, lo que llamamos curación (healing). La IA ve su propio error e intenta de nuevo, hasta tres veces.

Esto significa que los usuarios casi nunca ven un mensaje de "generación fallida". Ven un tiempo de generación ligeramente más largo y código funcional.

Etapa 3: Escaneo de seguridad del código

Esta es la etapa más importante. Ejecutamos un análisis estático que comprueba:

Funciones peligrosas: eval(), exec(), system(), shell_exec(), passthru() — cualquiera de ellas bloquea la liberación del plugin.

Vectores de inyección SQL: llamadas crudas a $wpdb->query() con variables interpoladas, falta de $wpdb->prepare(), uso directo de mysql_query().

Falta de comprobaciones de permisos: manejadores AJAX que no llaman a current_user_can() antes de realizar cualquier acción privilegiada.

Falta de verificación de nonce: procesadores de formularios que no llaman a wp_verify_nonce() o check_ajax_referer().

Salida sin escapar: echo $_GET[...], echo $user_input sin funciones de escape.

Si se encuentra alguno de estos, el plugin se bloquea. El usuario ve un informe que enumera exactamente qué funciones activaron el bloqueo y por qué, no solo "comprobación de seguridad fallida".

Cómo es el informe de auditoría

Cada plugin generado viene con un informe de auditoría de seguridad en lenguaje llano. Enumera:

• Qué comprobaciones pasaron (verde)
• Qué comprobaciones activaron advertencias (ámbar) — problemas que no son bloqueadores pero merecen atención
• Cualquier corrección que se aplicó automáticamente durante la curación

El informe se genera automáticamente y se adjunta a la descarga del plugin. Es útil tanto para su propia confianza como para mostrar a los clientes que se tomó en serio la seguridad.

Etapa 4: Validación al guardar

Esta no es parte de la generación inicial; se aplica cuando los usuarios editan manualmente el código del plugin en el editor de PAGEnza.

Cada vez que guarda, se vuelve a ejecutar el mismo lint + escaneo de seguridad. Si introduce una vulnerabilidad crítica mientras edita, el guardado se bloquea hasta que la corrija. Esto evita el escenario común en el que un desarrollador realiza un cambio rápido "temporal" que permanece en producción durante dos años.

Los límites de la auditoría automatizada

El escaneo automatizado detecta bien una clase específica de problemas. No lo detecta todo.

Los errores lógicos, la lógica de negocio rota y los problemas sutiles de escalada de privilegios que no involucran patrones peligrosos conocidos aún requieren una revisión humana. Somos transparentes al respecto en la documentación: la auditoría no reemplaza una revisión de seguridad, es un piso que garantiza un estándar mínimo.

Para plugins de producción que manejan pagos o datos sensibles, recomendamos una revisión manual además de las comprobaciones automatizadas. El informe de auditoría proporciona un buen punto de partida para un revisor humano.