Empiece por la decisión
«Necesitamos una revisión de seguridad» es un buen punto de partida, pero un alcance incompleto. ¿Va a lanzar un nuevo modelo de permisos, hereda un código ajeno o responde a la solicitud de evaluación de un cliente? Cada situación plantea una pregunta distinta. Escriba esa pregunta antes de elegir un servicio.
Ante un nuevo módulo de autorización, quizá necesite saber si el código aplica de forma coherente las reglas del producto. Ante una aplicación en funcionamiento, quizá necesite demostrar a qué puede acceder realmente un usuario con permisos limitados. Esos objetivos pueden dar lugar a trabajos complementarios.
Cuándo conviene partir del código fuente
La revisión de seguridad del código examina la implementación y su contexto: límites de confianza, flujo de datos, permisos y tratamiento de las entradas no fiables. Es útil cuando la pregunta se refiere a un módulo, a un cambio o a una posible causa raíz concretos. El acceso necesario puede incluir el código adyacente, las instrucciones de compilación y las pruebas.
Un buen resultado identifica las ubicaciones afectadas, explica el defecto y ofrece a los desarrolladores una corrección práctica y una forma de verificarla. El SAST automatizado puede apoyar la investigación, pero sus alertas siguen necesitando interpretación y validación. Pregunte qué módulos se revisan y cómo se respaldarán las conclusiones.
Cuándo prima el comportamiento en ejecución
Un pentest de aplicaciones investiga el producto a través de las interfaces y los vectores de ataque acordados. Las cuentas, los roles, los entornos y los límites operativos determinan lo que se puede probar. Resulta útil para comprobar si un flujo expuesto permite una acción no prevista y para entender su impacto observable.
El informe debe explicar el alcance probado, los hallazgos confirmados, los pasos de reproducción y las prioridades de corrección. El acceso al código fuente puede mejorar una evaluación cuando está disponible; un pentest no se limita automáticamente a un enfoque completamente a ciegas. Confirme el enfoque en la propuesta.
Combine los métodos en torno a una pregunta importante
Ante un cambio sensible en una API, revise el código de control de acceso correspondiente y después ejercite el comportamiento con los roles acordados. Ante un analizador nativo, revise el tratamiento de las entradas y de los tamaños, y valore pruebas dinámicas dirigidas o fuzzing cuando sea viable. Los métodos deben seguir al objetivo y a la meta.
Si el presupuesto es limitado, elija un componente o un flujo acotado y mantenga una profundidad útil. Acuerde por escrito los entregables, las exclusiones y cualquier verificación de las correcciones. Puedo ayudarle a definir ese alcance a partir de una breve descripción de su producto, su stack y el motivo de la revisión.
Fuentes
¿Necesita que se compruebe esto en su propio producto?
Pruebas de penetración de aplicaciones¿Quiere aprender a encontrar vulnerabilidades como esta por su cuenta?
Curso individual de pentesting de aplicaciones web