En resumen: una revisión de código de seguridad para PHP es la lectura dirigida del código fuente con una pregunta: ¿dónde pueden las entradas externas hacer algo que no deben? Dan buen resultado dos formas: una revisión de cada cambio y una revisión base de todo el proyecto, apoyadas en análisis estático con PHPStan o Psalm. Una revisión no encuentra vulnerabilidades del intérprete de PHP como PHP2Shell, pero sí los muchos errores que surgen en el código propio.
¿Por qué mirar justo ahora el código propio?
En la última semana de octubre de 2026, PHP2Shell ocupó sobre todo a los administradores. Parchear, reiniciar, demostrarlo: el trabajo estaba en el servidor. Para los equipos de desarrollo queda después una pregunta incómoda. Si un atacante puede ejecutar código a través de otra vulnerabilidad, ¿qué encuentra en nuestra aplicación? ¿Y cuántas de esas vulnerabilidades hemos escrito nosotros mismos?
El OWASP Top 10 muestra desde hace años que la mayoría de las vulnerabilidades de las aplicaciones web no son exóticas. La falta de control de acceso, la inyección y la configuración insegura figuran en los primeros puestos. Son errores que una mirada experimentada encuentra en el código fuente mucho antes de que un atacante los pruebe.
A ello se suma una razón práctica. Muchas empresas están haciendo revisar, parchear y reforzar sus servidores. Quien mira la propia aplicación a la vez cierra la brecha entre operación y desarrollo. Un servidor reforzado con una aplicación vulnerable sigue siendo atacable, y una aplicación bien escrita sobre un PHP sin parchear, también.
¿Revisión base o revisión de cambios?
La hoja de referencia de OWASP sobre Secure Code Review distingue dos tipos que en la práctica se complementan:
| Tipo | Cuándo | Alcance | Objetivo |
|---|---|---|---|
| Revisión base (baseline) | Proyecto nuevo, release importante, tras un incidente | Todo el proyecto, ponderado por riesgo | Registrar las vulnerabilidades existentes |
| Revisión de cambios (diff) | Cada pull request | Solo el código modificado | Evitar errores nuevos |
Una revisión base tras un incidente es especialmente valiosa. Quien acaba de limpiar un servidor debería saber si la aplicación ofrece más puertas de entrada. La revisión de cambios mantiene después limpio el estado, porque cada cambio se lee también desde el punto de vista de la seguridad antes de integrarse.
Revisión de código en PHP: dónde se acumulan los errores de seguridad
En los proyectos PHP merece la pena una mirada dirigida a determinadas funciones y patrones. No están prohibidos, pero cada hallazgo merece la pregunta de si pueden llegar datos ajenos.
| Patrón en el código | Posible riesgo | Para profundizar |
|---|---|---|
| SQL por concatenación de cadenas con variables | Inyección SQL | Evitar la inyección SQL en PHP |
unserialize() sobre datos externos |
Inyección de objetos | Deserialización insegura en PHP |
include o require con ruta variable |
Inclusión de archivos ajenos | Evitar la inclusión local y remota de archivos |
exec(), system(), shell_exec(), proc_open() |
Ejecución de comandos | Inyección de comandos |
Salida sin htmlspecialchars() |
Cross-site scripting | Escapado adecuado al contexto |
== con tokens o hashes |
La conversión de tipos elude las comprobaciones | hash_equals(), comparaciones estrictas |
eval(), extract() sobre entradas |
Inyección de código o de variables | Normalmente, eliminar sin sustituto |
Una primera visión general rápida se logra con una búsqueda sencilla. No sustituye a una revisión, pero muestra por dónde empezar:
# Hallazgos de funciones de riesgo en el código propio (excluido vendor)
grep -rnE "\b(unserialize|eval|extract|shell_exec|exec|system|passthru|proc_open)\s*\(" src/ app/ 2>/dev/null
Al menos igual de importante es lo que falta en el código. ¿Comprueba cada controlador si el usuario autenticado puede ver o modificar precisamente este registro? ¿Se limitan las subidas por tipo y lugar de almacenamiento? Esas lagunas no las encuentra ninguna búsqueda de nombres de función, solo la lectura del flujo.
Herramientas que sostienen la revisión
El análisis estático comprueba el código sin ejecutarlo. PHPStan y Psalm encuentran errores de tipo, código inalcanzable y suposiciones erróneas sobre valores de retorno. Psalm ofrece además un análisis de taint, que sigue si datos de las peticiones fluyen sin comprobar hacia puntos críticos. Ambos pueden endurecerse por niveles, de modo que también los proyectos más antiguos pueden empezar. Una visión general la da Análisis estático: PHPStan y Psalm.
# Análisis estático en el proyecto, aumentar el nivel paso a paso
vendor/bin/phpstan analyse src --level=5
# Análisis de taint con Psalm
vendor/bin/psalm --taint-analysis
Las herramientas dan indicios, no veredictos. Cada resultado necesita una valoración, y un informe vacío no significa que la aplicación sea segura.
Tan importante como encontrar es dejar constancia. Cada hallazgo debería registrarse con su ubicación, una breve descripción, una valoración del riesgo, la corrección recomendada y el estado, a ser posible directamente en el sistema de tickets del equipo. Así puede seguirse qué se ha corregido, qué se ha aceptado deliberadamente y qué sigue abierto. Tras la corrección merece la pena una segunda mirada: ¿se ha eliminado la causa o solo un síntoma? ¿Aparece el mismo patrón en otros puntos del código? Según la experiencia, un error que se ha cometido una vez rara vez está en un solo lugar.
Una lista de comprobación para su equipo
Para las revisiones de cambios ha dado buen resultado una lista corta y fija. Pertenece a la plantilla de los pull requests:
- ¿De dónde proceden todos los datos que procesa este cambio y se comprueban en el servidor?
- ¿Se construyen las consultas a la base de datos exclusivamente con marcadores de posición?
- ¿Está escapada cada salida para su contexto, es decir, HTML, atributo, JavaScript o URL?
- ¿Comprueba el código el permiso para precisamente este objeto, y no solo el inicio de sesión?
- ¿Llegan contraseñas, tokens o datos personales a logs o mensajes de error?
- ¿Hay secretos en el código o en archivos versionados?
- ¿Se han incorporado nuevas dependencias y están mantenidas?
Haga que las partes críticas para la seguridad, como inicio de sesión, gestión de permisos, flujos de pago y subidas, las lea siempre una segunda persona que no haya participado en el código. La mirada ajena encuentra suposiciones que el autor da por evidentes.
¿Cómo ayuda PHP SOS en concreto?
- Con socios especializados, realizamos una revisión base de su aplicación PHP, ponderada según las partes de mayor riesgo.
- Configuramos PHPStan o Psalm adecuados al estado de su proyecto y redactamos la lista de comprobación para sus pull requests.
- Vinculamos la revisión con una mirada al servidor y a la configuración, porque muchas vulnerabilidades surgen solo en la interacción.
- Cuando se desea una comprobación desde fuera, complementamos la revisión con una auditoría de seguridad y prueba de penetración.
Conclusión: una revisión de código es el lugar más barato para corregir errores de seguridad, es decir, antes de que se entreguen. Quien revisa cada cambio con una lista corta y examina de vez en cuando el proyecto completo reduce la superficie de ataque de forma duradera.
Preguntas frecuentes
¿Qué diferencia hay entre una revisión de código y una prueba de penetración?
Una revisión de código lee el código fuente y encuentra errores antes de que se entreguen. Una prueba de penetración ataca desde fuera la aplicación en funcionamiento. Ambas se complementan: la revisión encuentra las causas; la prueba muestra qué es realmente explotable.
¿Encuentra una revisión de código vulnerabilidades como PHP2Shell?
No. PHP2Shell está en el intérprete de PHP, no en el código de la aplicación. Frente a ello solo ayuda una actualización de PHP con reinicio. Una revisión encuentra errores en el código propio, como inyección, comprobaciones de permisos ausentes o deserialización insegura.
¿Bastan PHPStan o Psalm para una revisión de seguridad?
Son una buena base y encuentran automáticamente muchos errores. Pero los errores lógicos, las comprobaciones de permisos ausentes y las suposiciones erróneas sobre los flujos solo las reconoce una persona que sepa lo que debe hacer la aplicación.
¿Cuánto dura una revisión de código de seguridad?
Depende del alcance. Una revisión de cada cambio en el pull request cuesta poco tiempo. Una revisión completa de un proyecto que ha ido creciendo es un proyecto en sí mismo, que se limita según el riesgo a las partes más importantes.