En resumen: un framework de PHP es una estructura base de código reutilizable que ya resuelve tareas típicas de una aplicación web: dirigir las peticiones al código correcto, procesar datos de formularios, acceder a bases de datos, generar salidas. Frameworks de PHP conocidos son Laravel, Symfony, Laminas, CodeIgniter, Yii, CakePHP y Slim. Un framework aporta componentes de seguridad, pero no protege frente a vulnerabilidades del intérprete de PHP como PHP2Shell.
¿Qué es un framework de PHP?
Sin framework, cada equipo escribe de nuevo el enrutamiento, la validación de formularios, las sesiones y el tratamiento de errores. Un framework establece para ello componentes y convenciones fijos. Eso ahorra tiempo, hace que el código sea legible para nuevos desarrolladores y concentra las funciones de seguridad en un solo lugar, en lugar de repartirlas por cientos de archivos.
Para la dirección es importante sobre todo una consecuencia: al elegir un framework se ata durante años a su ciclo de versiones. Si el framework deja de admitir una versión de PHP o él mismo deja de mantenerse, cada actualización resulta más cara.
La mayoría de los frameworks modernos se instalan mediante Composer y se atienen a los estándares de PHP-FIG, como PSR-4 para el autoloading o PSR-7 para los mensajes HTTP.
Los frameworks de PHP conocidos, comparados
El siguiente resumen utiliza las autodescripciones de los proyectos en sus páginas de inicio. Omitimos deliberadamente las valoraciones por popularidad o cuota de mercado, porque no existe una fuente común fiable para ello.
| Framework | Autodescripción (en esencia) | Uso típico |
|---|---|---|
| Laravel | framework con «baterías incluidas» para aplicaciones web | desarrollos propios, portales, SaaS |
| Symfony | framework potente con componentes reutilizables | aplicaciones grandes y duraderas; componentes en otros proyectos |
| Laminas | continuación del Zend Framework mantenida por la comunidad | aplicaciones empresariales, middleware |
| CodeIgniter | framework pequeño con funciones potentes | aplicaciones más pequeñas, barrera de entrada baja |
| Yii | framework para el desarrollo rápido de aplicaciones modernas | aplicaciones web, base de algunos CMS |
| CakePHP | framework con convenciones MVC claras | aplicaciones clásicas de bases de datos |
| Slim | micro-framework para aplicaciones web y API | API ligeras, servicios de middleware |
Symfony menciona en su página de inicio a Drupal, Laravel, API Platform y Composer como proyectos que utilizan componentes de Symfony. Por tanto, un framework suele estar también donde no se ve directamente. Cómo es esto en CMS y tiendas lo muestra la página CMS y sistemas de tienda en PHP.
Componentes comunes de casi todos los frameworks
A pesar de sus filosofías distintas, la mayoría de los frameworks comparten una estructura. Todas las peticiones pasan por un único punto de entrada, el front controller, normalmente public/index.php. Para ello, el servidor web pasa a este archivo cualquier dirección para la que no exista un archivo real.
# Ejemplo: Nginx dirige las rutas desconocidas al front controller
root /var/www/app/public;
location / {
try_files $uri /index.php$is_args$args;
}
En Apache, esta tarea la asume normalmente una regla de reescritura en la carpeta pública; en otros servidores web, una regla equivalente. En todos los casos es importante que el servidor web apunte a la carpeta public y no al directorio principal del proyecto. Un directorio de documentos mal configurado es una de las causas más frecuentes de que los archivos de configuración se puedan consultar de repente públicamente.
La ventaja para la seguridad: solo la carpeta public está en la raíz web. La configuración, el código fuente y vendor están un nivel por encima y no son accesibles mediante URL. Después, el router asigna la petición a un controlador, el middleware comprueba el inicio de sesión o el token CSRF y un motor de plantillas genera la salida con escape automático.
¿Cómo se elige un framework?
Para un desarrollo nuevo o para hacerse cargo de un proyecto existente ayudan estas preguntas:
- Mantenimiento y ciclo de versiones: ¿durante cuánto tiempo se atienden las versiones con actualizaciones de seguridad y hay versiones con soporte ampliado?
- Compatibilidad con PHP: ¿se ejecuta la versión del framework utilizada en una versión de PHP que aún recibe actualizaciones de seguridad? Eso consta en los requisitos del proyecto.
- Equipo y proveedores: ¿conoce el equipo el framework y encontrará especialistas en caso de emergencia?
- Ecosistema: ¿hay paquetes mantenidos para sus requisitos o habría que construir mucho por cuenta propia?
- Estándares: si el framework se atiene a las interfaces PSR, los componentes podrán sustituirse más fácilmente después.
Para los proyectos con Laravel y Symfony tenemos páginas propias sobre su protección: Proteger aplicaciones Laravel y Proteger aplicaciones Symfony.
Qué aporta un framework a la seguridad y qué no
Los frameworks quitan a los desarrolladores muchas fuentes de error: consultas preparadas a la base de datos contra la inyección SQL, escape automático contra el cross-site scripting, protección CSRF para formularios, hashes de contraseñas seguros. Pero esto solo funciona si el equipo usa estos componentes y no los elude.
Frente a PHP2Shell, nada de esto ayuda. CVE-2026-109618 y CVE-2026-109619 están en el intérprete de PHP. El equipo de PHP considera que el riesgo es mayor en mod_php; allí se demostró un exploit antes de que se ejecute siquiera código de la aplicación. El framework ni siquiera llega a intervenir. Solo remedia la actualización a PHP 8.5.12, 8.4.27, 8.3.36 o 8.2.35 y el reinicio de todos los procesos de PHP.
Una actualización del framework y una actualización de PHP son dos tareas separadas. Ambas pertenecen al mantenimiento, pero solo la actualización de PHP cierra PHP2Shell.
En los proyectos antiguos se añade otro riesgo: si una aplicación depende de una versión antigua del framework, a menudo depende también de una versión antigua de PHP. Para PHP 8.1 y anteriores, el proyecto PHP ya no ofrece actualizaciones oficiales.
¿Cómo ayuda PHP SOS en concreto?
- Averiguamos el framework, la versión y los requisitos de PHP de su aplicación y comprobamos si ambos siguen recibiendo actualizaciones de seguridad.
- Revisamos la estructura: ¿está solo
publicen la raíz web y están protegidos la configuración yvendor? - Planificamos por separado las actualizaciones del framework y de PHP, las probamos y las instalamos con reinicio de todos los workers.
- Para los desarrollos propios ofrecemos una auditoría de seguridad y prueba de penetración que revisa de forma específica el uso de las funciones de protección del framework.
Preguntas frecuentes
¿Cuál es el mejor framework de PHP?
Depende del proyecto. Son decisivos el tamaño y la vida útil de la aplicación, los conocimientos del equipo, el mantenimiento por parte del proyecto y la compatibilidad con versiones actuales de PHP. Un framework bien mantenido y conocido por el equipo suele ser mejor opción que el que esté de moda.
¿Protege un framework frente a PHP2Shell?
No. PHP2Shell está en el intérprete de PHP y, según el equipo de PHP, en mod_php se demostró un exploit antes de que se ejecute siquiera código de la aplicación. Ninguna actualización del framework sustituye la actualización del entorno de ejecución de PHP y el reinicio de todos los workers.
¿Qué es un micro-framework?
Un micro-framework ofrece solo el núcleo, normalmente enrutamiento, middleware y objetos de petición y respuesta. El acceso a bases de datos, las plantillas o los formularios se eligen aparte. Slim, por ejemplo, se define a sí mismo como un micro-framework para PHP.
¿Qué significa que un CMS use componentes de Symfony?
Utiliza componentes individuales de Symfony, por ejemplo para el tratamiento de HTTP o la consola, sin adoptar todo el framework. Los avisos de seguridad sobre esos componentes afectan entonces también al CMS, algo que cuenta en la planificación de actualizaciones.