Revisión de seguridad del frontend: páginas que un usuario no debería ver
Una revisión de seguridad del frontend verifica las páginas, las cookies y los archivos subidos a los que puede acceder un usuario con sesión iniciada. Una aplicación cuesta $2,400 de pago único, $1,200 para empezar, sin suscripción.
Una revisión de seguridad del frontend es el pase en el que abro lo que puede abrir un usuario con sesión iniciada.
Si la página se muestra para el rol equivocado, eso ya es un hallazgo. No necesitas un red team de seis semanas para enterarte de que un cliente puede ver una exportación del personal.
Respuesta corta: Una revisión de seguridad del frontend cubre rutas, formularios, cargas, descargas, cookies y tokens en una sola aplicación. Eso lo vendo dentro de una revisión de seguridad de aplicaciones web por $2,400 de pago único, $1,200 para empezar. El informe se entrega 48 horas después de que el acceso funcione. El PDF es tuyo. No hay suscripción.
El Top 10 de OWASP de 2021 pone el control de acceso roto en primer lugar. Su conjunto de datos dice que el 94% de las aplicaciones fue probado para eso, con una incidencia promedio de 3.81% y más de 318,000 ocurrencias. Eso es cobertura de la prueba, no “el 94% de las apps están abiertas de par en par.” Sigue siendo la clase sobre la que espero escribir cuando un producto tiene cuentas.
¿Qué revisa de verdad una revisión de seguridad del frontend?
Recorro la interfaz en vivo con los roles que me das: cada ruta que se muestra, cada formulario que se envía, cada archivo que se carga o se descarga, y lo que la cookie o el token todavía permite después de cerrar sesión o de un cambio de rol.
La tabla es el trabajo. El precio es por una aplicación, de pago único.
| Chequeo | En el pase de $2,400 | Fuera de este pase |
|---|---|---|
| Rutas que un rol puede abrir, incluidas las que el menú oculta | Sí | Un segundo producto en otro host |
| Cookies, tokens, cierre de sesión y el comportamiento del botón atrás | Sí | Permisos de administrador dentro de tu proveedor de identidad |
| Formularios, cargas, exportaciones y descargas | Sí | Una auditoría del código fuente línea por línea |
| APIs que esas páginas ya llaman | Sí, el mismo trabajo | Una factura aparte “solo API” |
| Una nueva prueba de la misma URL dentro de 14 días | Sí | Funciones que publicas después de esa nueva prueba |
| PDF de un escáner o un certificado de cumplimiento | No | No vendo ninguno de los dos |
El inicio de sesión en sí — restablecimiento, invitación, mapeo de SSO — es el pase hermano que describo en revisión de seguridad de autenticación. La misma factura. Otra hora del trabajo.
¿A qué páginas no debería llegar nunca un usuario con sesión iniciada?
Si un cliente puede abrir una ruta del personal, una exportación de facturación o el registro de otro tenant usando la app tal como está hecha, esa página está dentro del alcance. Trato una pantalla que se muestra como el hallazgo.
No estoy cazando URLs ocultas con una lista de palabras como plato principal. Empiezo desde el producto:
- Una URL de miembro que todavía se muestra en un navegador sin sesión
- Una pantalla de administrador enlazada en el HTML aunque el menú la oculte
- Una descarga que ignora el rol del botón
- Una carga que acepta un archivo que ese rol nunca debería enviar
- Un registro que pertenece a otra organización y aun así se abre
El último suele controlarse en la API, no en el árbol de React. Igual llego a él desde la página. Cómo escribo ese hallazgo, sin una receta, es el punto de la nota de IDOR.
Ocultar el menú no es un control. Si la ruta responde, la trato como accesible.
¿Qué deberían hacer la cookie y el token?
Después de cerrar sesión, de un cambio de rol o de una sesión que querías terminar, el navegador debería dejar de ser ese usuario. Si la página de la cuenta todavía se pinta, la sesión falló. Registro la ruta y el rol, no el valor de la cookie.
Miro el comportamiento que puedes ver, no un volcado de los flags de tu cookie por sí mismos:
- Cerrar sesión y luego el botón atrás o una recarga
- Un token que la página guarda y que sigue funcionando después de que el usuario cierra sesión
- Una sesión que sobrevive a un cambio de contraseña que me dijiste que esperara
- Dos roles en un mismo navegador, y si las páginas del primer rol siguen ahí
No pego valores de cookies en el PDF. La evidencia es la ruta, el rol y lo que se mostró.
Esto no es perseguir facturas ni una insignia de reservas dentro de ChatGPT. Esos son One Lane y Business MCP. Una revisión de seguridad no envía tu reporte del viernes ni toma un trabajo de Jobber.
¿Qué queda fuera de los $2,400?
Auditoría del código fuente, un binario móvil, phishing, una segunda aplicación y cualquier carta que exista solo para cumplir un sello de compras. El precio de $2,400 es una URL, de pago único, sin asiento mensual.
Estás comprando tiempo en una URL. Frontend, autenticación y las APIs que la interfaz ya llama. Los números están en precios: $2,400 por app, $1,200 para empezar, el resto cuando se entrega el informe. Una nueva prueba gratis de esa misma URL dentro de 14 días.
No incluye:
- Leer el repositorio como un encargo aparte
- Tu tenant del IdP como administrador
- Nombres de host ilimitados porque comparten una marca
- Pasos de explotación que alguien de afuera podría copiar
- Una carta de CREST, PCI o SOC que no estoy certificado para firmar
No invento certificaciones. Si el contrato de un cliente exige un sello con nombre, contrata a la firma que lo tiene.
¿Cómo corre el pase?
El disparador es un permiso por escrito más un usuario que pueda iniciar sesión. La acción es el recorrido de las páginas. El sistema de registro es el PDF. Una persona publica la corrección y después yo vuelvo a probar la misma URL una vez.
- Autorizas la URL, indicas prod o staging y listas lo que queda fuera.
- Inicio sesión con el rol que me diste y recorro rutas, formularios, cargas y descargas.
- Restauro los datos de prueba que creé.
- Recibes la severidad, la ruta, el rol y una corrección que un ingeniero puede dejar en un ticket.
- Tú corriges. Yo vuelvo a probar esa URL una vez, gratis, dentro de 14 días.
El reloj empieza cuando el inicio de sesión funciona, no cuando se cobra la tarjeta. Un SaaS amplio puede caer en una ventana de 24–72 horas. El acceso roto es una pausa, no un temporizador silencioso.
Si quieres la forma del documento antes de las credenciales, pide la muestra en el formulario de contacto.
Cuando esto todavía no es el paso correcto
Espera si no hay inicio de sesión, si no puedes autorizar la URL o si necesitas un sello de cumplimiento en lugar de una lista de tickets. Un sitio de marketing y un mock de autenticación a medio armar llegan demasiado pronto. También es demasiado pronto comprar esto cuando la fuga real son las facturas o una reserva por chat.
Espera si alguna de estas es cierta.
- El sitio no tiene cuentas. Una página de marketing no necesita este pase.
- El inicio de sesión sigue siendo un simulacro. No hay nada que autorizar.
- No puedes nombrar a una persona dueña de la URL.
- Necesitas un sello de cumplimiento, no una lista de tickets.
- Querías que alguien persiguiera facturas o agendara trabajos desde una app de chat. Esa es otra oferta y otra página.
Cómpralo cuando una app de producción o de staging tenga usuarios reales, puedas dar una cuenta de prueba y el equipo de ingeniería de verdad vaya a leer una lista priorizada esta semana.
Empieza en la página de la revisión. $1,200 reserva el trabajo. Confirmo el alcance por escrito. No agendo una llamada para explicar la misma oferta.
Preguntas frecuentes
What is a frontend security review? +
It is an authorized pass over what a signed-in user can open: routes, forms, uploads, downloads, cookies, and tokens. I include that in the same $2,400 review as login and the APIs those pages already call. It is not a source read and not a scanner certificate.
Is the frontend included in the $2,400 price? +
Yes. One application is $2,400 once, with $1,200 to start and $1,200 when the report is delivered. Frontend, session, auth, and the APIs the UI already calls are one job. A second app is a second quote. There is no monthly fee.
Do you need two user roles? +
A second role makes the page checks sharper. I can still review a single role and write that limit in the note. I do not need admin on your identity provider. I need a user that can sign in on the URL you named.
Will the PDF include exploit steps? +
No. Findings name the route or action, the role, the severity, and a fix an engineer can ship. No payloads, no leftover credentials, and no client names. Ask for the redacted sample before you send access if you want the format first.
