Revisión de seguridad del código

Una auditoría vista desde fuera prueba las puertas visibles. Leer el código es abrir el capó y detectar lo que se esconde dentro: un secreto olvidado, una entrada mal filtrada, una dependencia vulnerable. FastSolve examina su código en el origen, antes de que un atacante encuentre ahí la brecha.

Esta prestación requiere un acceso de lectura a su código y una autorización escrita. El código permanece con usted; nada se conserva ni se comparte.

Esta prestación se factura sobre presupuesto aceptado. Una auditoría entrega una constatación, no una herramienta: la regla habitual, probar antes de pagar, no puede aplicarse aquí. El presupuesto indica de antemano qué incluye y hasta dónde llega el análisis.

Lo que se esconde en el código

Algunas brechas no dejan ningún rastro visible desde fuera. Esperan, escritas en claro en los archivos, hasta que alguien les echa mano.

• Una contraseña, una clave de acceso o un token escritos directamente en el código, a veces copiados sin querer en un repositorio compartido.
• Una entrada del usuario que llega hasta la base de datos sin control, abriendo la vía a una inyección.
• Un componente externo que se quedó en una versión antigua, cuya brecha es públicamente conocida y documentada.
• Un fragmento de código tomado de un foro que funciona, pero que arrastra una vulnerabilidad conocida.

Estos defectos no se adivinan desde la página de inicio. Se leen, línea por línea, ahí donde se escribieron.

Qué cubre la revisión

La lectura se dirige a los lugares donde un error de código se convierte en una brecha de seguridad.

1. Los secretos y la configuración

Rastreamos credenciales, claves y tokens escritos de forma fija, y comprobamos que la configuración separe bien lo público de lo que debe quedar oculto.

Situación típica. Una clave de acceso a un servicio de pago dormía en un archivo seguido por el repositorio. Sacarla del código y sustituirla cerró una puerta que nadie había visto.

2. El tratamiento de las entradas

Seguimos el camino de los datos enviados por el usuario hasta la base de datos o la visualización, para asegurarnos de que ninguno se ejecute donde solo debería leerse.

Situación típica. Una consulta a la base de datos se construía pegando directamente la entrada del usuario. Reescribirla como consulta preparada eliminó el riesgo de inyección.

3. La lógica de los accesos

Comprobamos que los controles de permisos estén del lado del servidor, y no solo ocultos en pantalla, porque lo que se oculta a la vista sigue siendo accesible por otra vía.

Situación típica. Un botón de administración estaba simplemente oculto para las cuentas ordinarias, pero la acción seguía siendo accesible invocándola directamente. Un control del lado del servidor restableció la barrera.

4. Las dependencias

Enumeramos los componentes externos y sus versiones, detectamos los que tienen una brecha conocida, e indicamos cuáles actualizar primero.

Situación típica. Un componente de envío de correos iba varias versiones por detrás, con una brecha publicada. Actualizarlo llevó unos minutos, una vez identificado el riesgo.

Lo que la revisión no hace

Ilumina el código desde el ángulo de la seguridad. No reescribe su proyecto ni juzga sus decisiones técnicas.

• No sustituye la auditoría vista desde fuera: las dos miradas se complementan, una prueba las puertas, la otra lee las cerraduras.
• No reescribe su aplicación. Señala los puntos de riesgo y cómo corregirlos, siendo la corrección un trabajo aparte.
• No garantiza la ausencia total de brechas: ninguna lectura puede hacerlo. Reduce fuertemente lo conocido y evitable.
• Necesita acceder al código. Sin leer las fuentes, este servicio no tiene objeto, y es la auditoría externa la que conviene.

Le entregamos una lista clara de lo que vale la pena corregir, sin jerga inútil y sin dramatizar lo que no lo merece.

Preguntas frecuentes

Díganos qué código le gustaría que revisáramos

Ver cómo se desarrolla un proyecto, del encuadre a la entrega
Ver todos los servicios de FastSolve