OWASP Top 10:2025 en WordPress, explicado

El OWASP Top 10 es la lista más conocida de riesgos de seguridad para aplicaciones web, y su edición de 2025 sustituye a la lista de 2021. Aplicada a WordPress, se lee como un mapa de cómo se entra de verdad en los sitios: comprobaciones de permisos que faltan en los plugins, configuraciones descuidadas y componentes desactualizados o abandonados.

Esta guía traduce cada uno de los diez riesgos al lenguaje de WordPress y muestra cuáles puede comprobar hoy mismo el propietario del sitio y cuáles solo pueden corregir los desarrolladores en el código.

Qué es el OWASP Top 10 y qué no es

La lista la publica la OWASP Foundation, una comunidad sin ánimo de lucro dedicada a la seguridad del software. OWASP la describe como «a standard awareness document for developers and web application security» (un documento estándar de concienciación para desarrolladores y sobre la seguridad de las aplicaciones web): una clasificación de las categorías de riesgo más críticas, elaborada a partir de datos de vulnerabilidades y de una encuesta a la comunidad.

No es una certificación, y ningún sitio es «conforme con OWASP». Úsela para decidir dónde mirar primero. Si necesita una lista detallada de requisitos verificables, OWASP publica para ello el Application Security Verification Standard (ASVS).

Qué ha cambiado en 2025

Respecto a 2021, el OWASP Top 10:2025 incorpora dos categorías nuevas y algunos cambios de posición:

• A03 Software Supply Chain Failures es nueva. Amplía la antigua «Vulnerable and Outdated Components» (componentes vulnerables y desactualizados) a todo aquello con lo que usted construye y actualiza su sitio.
• A10 Mishandling of Exceptional Conditions es nueva: mala gestión de errores, fallos de lógica y sistemas que «fallan en abierto» (fail open).
• La falsificación de solicitudes del lado del servidor (SSRF) ya no es una categoría propia; ahora forma parte de A01 Broken Access Control.
• Security Misconfiguration (configuración de seguridad incorrecta) ha subido del quinto al segundo puesto.
• A09 se llama ahora Security Logging and Alerting Failures, un recordatorio de que los registros que nadie lee no sirven de nada.

Los diez riesgos en clave de WordPress

El control de acceso defectuoso (broken access control) también encabeza la lista en WordPress: el informe de Patchstack State of WordPress Security in 2026 lo señala como la categoría de vulnerabilidad más explotada de 2025. Patchstack es una empresa de seguridad, así que tómelo como una fuente bien informada, no como la única.

Cinco riesgos que el propietario del sitio puede comprobar hoy

Para estos no hace falta leer código. Cada comprobación le llevará unos minutos desde el escritorio o con WP-CLI.

A03: conozca y actualice sus componentes

La mayoría de las vulnerabilidades de WordPress están en plugins y temas, no en el núcleo. Mantenga un inventario, instale cuanto antes las actualizaciones de seguridad y elimine lo que no use. Este comando muestra los plugins que tienen una actualización pendiente:

wp plugin list --update=available --fields=name,version,update_version

Nuestra guía sobre plugins vulnerables de WordPress trata en detalle los plugins abandonados y las copias «nulled».

A02 y A10: oculte los errores a los visitantes

Un sitio en producción nunca debería mostrar errores ni avisos de PHP, porque revelan rutas de archivos y, a veces, datos de la base de datos. En wp-config.php, mantenga la depuración desactivada en producción:

define( 'WP_DEBUG', false );
define( 'WP_DEBUG_DISPLAY', false );

Asegúrese también de que su servidor no muestre el contenido de los directorios y de que no se pueda acceder a ningún archivo de copia de seguridad o de exportación dentro de la raíz web.

A07: proteja cada inicio de sesión

Active la autenticación de dos factores para todos los administradores y editores, y limite los intentos de acceso fallidos. Nuestra guía de autenticación de dos factores para WordPress explica las opciones, desde las apps de autenticación hasta las llaves de acceso (passkeys).

A08: compruebe que los archivos son originales

WP-CLI compara sus archivos con las sumas de verificación oficiales de WordPress.org:

wp core verify-checksums
wp plugin verify-checksums --all

Cualquier archivo del núcleo modificado o desconocido merece una revisión. Los plugins que no proceden de WordPress.org no pueden comprobarse así; compárelos con una descarga reciente del sitio del proveedor.

A09: lleve un registro y reciba alertas

Registre los inicios de sesión, los usuarios nuevos, los cambios de rol, las instalaciones de plugins y los cambios en archivos, y asegúrese de que alguien reciba el aviso. Sin estos registros no podrá saber qué ocurrió tras un incidente ni cumplir el plazo de notificación de 72 horas del RGPD que describimos en nuestra guía sobre brechas de datos.

Tres riesgos que solo pueden corregir los desarrolladores

Si desarrolla plugins o temas, A01, A05 y A10 se reducen sobre todo a usar con constancia unas pocas funciones de WordPress.

• Control de acceso (A01): compruebe current_user_can() antes de cada acción privilegiada, verifique los nonces con check_ajax_referer() o wp_verify_nonce() y dé a cada ruta REST un permission_callback. Desde WordPress 5.5, una ruta sin él genera un aviso (notice); para las rutas que deben ser públicas, WordPress recomienda __return_true.
• SSRF (ahora parte de A01): cuando solicite una URL facilitada por un usuario, use wp_safe_remote_get(). Esta función valida la dirección y cada redirección, y rechaza por defecto las redes locales y privadas.
• Inyección (A05): construya las consultas con $wpdb->prepare(), sanee la entrada en cuanto llega (sanitize_text_field(), absint()) y escape la salida lo más tarde posible (esc_html(), esc_attr(), esc_url()).
• Condiciones excepcionales (A10): compruebe is_wp_error() en cada llamada que pueda fallar y haga que las comprobaciones de seguridad fallen en cerrado: si una comprobación de permisos o de licencia no puede completarse, deniegue la acción.

Una ruta REST que sigue estas reglas tiene este aspecto:

register_rest_route( 'myplugin/v1', '/report', array(
    'methods'             => 'POST',
    'callback'            => 'myplugin_save_report',
    'permission_callback' => function () {
        return current_user_can( 'manage_options' );
    },
) );

El capítulo de seguridad del manual para desarrolladores de WordPress explica cada función con ejemplos.

OWASP, RGPD y NIS2

El OWASP Top 10 no es una ley, pero es una referencia habitual del «estado de la técnica» en seguridad web. El art. 32 del RGPD exige medidas técnicas apropiadas y un proceso de verificación, evaluación y valoración regulares de su eficacia. Revisar un sitio WordPress frente a las diez categorías es una forma práctica de demostrar ese proceso.

Para las organizaciones incluidas en el ámbito de la NIS2, el art. 21, apartado 2, enumera entre las medidas mínimas la seguridad en la adquisición, el desarrollo y el mantenimiento, incluida la gestión de vulnerabilidades. A03 y A05 encajan directamente con esa obligación.

Nuestro plugin Security Audit & Compliance asigna cada hallazgo a una categoría del OWASP Top 10:2025, junto al art. 32 del RGPD y el art. 21 de la NIS2, de modo que el informe muestra a qué riesgo pertenece cada problema. Detecta e informa; la decisión de corregir sigue siendo suya. Vea qué comprueba.

Preguntas frecuentes

¿Es el OWASP Top 10 una obligación legal?

No. Es un documento de concienciación. Leyes como el RGPD exigen una seguridad apropiada, y el Top 10 le ayuda a decidir qué significa eso para un sitio web.

¿Tengo que repetir mi revisión de seguridad por la edición de 2025?

No desde cero. La mayoría de los riesgos se mantienen; actualice sus notas con las nuevas categorías A03 y A10 y con la nueva numeración.

¿Es el propio núcleo de WordPress un gran riesgo OWASP?

Rara vez. Patchstack contabilizó seis vulnerabilidades del núcleo en 2025, todas de prioridad baja, frente a miles en plugins y temas. El riesgo está en su lista de plugins.

Este artículo es información general, no asesoramiento jurídico.