Revisar tu aplicación antes de publicarla: los 23 fallos que encontró una auditoría

La última semana sirve para escribir el anuncio, preparar las capturas y avisar a los primeros clientes. Dos revisiones de seguridad encargadas antes del lanzamiento, una relatada por quien la encargó y otra por el proveedor que la realizó, muestran qué más debería incluir esa semana y por qué la lista cabe en cinco días de trabajo normal.

El propietario de un marketplace construido sin programar cuenta en Reddit (r/nocode, agosto de 2026) que la auditoría encargada antes de publicarlo produjo 23 hallazgos repartidos en cuatro niveles de gravedad, entre ellos uno que permitía al comprador fijar él mismo el precio de los productos. Revisar tu aplicación antes de publicarla requiere una semana y una lista.

Lo que encontraron dos revisiones

Los tres primeros hallazgos del marketplace se refieren al precio fijado por el comprador al pagar, a controles de acceso ausentes y a datos modificables sin autenticación. Una segunda revisión, descrita por un proveedor en r/vibecoding (julio de 2026), encontró algo distinto: cada visitante de la demostración creaba en silencio una empresa, un espacio de trabajo y un perfil permanentes en la base utilizada en producción, y cinco reglas de seguridad concedían un acceso más amplio de lo previsto. Quien la encargó esperaba miles de cuentas falsas en las horas posteriores a la apertura. Ninguno de estos defectos se ve en pantalla y ninguno impedía que la aplicación funcionara. Las dos revisiones se encargaron antes de abrir al público; las que no se encargan dejan que la aplicación salga el día previsto, con los mismos defectos y sin la lista que los identifica.

El recorrido ideal y todo lo demás

Otro testimonio (r/vibecoding, agosto de 2026) expresa la duda que comparten la mayoría de quienes encargan un producto: su autor no sabía si sus puntos de entrada comprobaban los permisos en el servidor ni si un usuario podía recuperar datos de otro adivinando un identificador. Su prototipo se había publicado en un fin de semana, para un trabajo que antes estimaba en meses. La IA construye el recorrido que se le ha descrito, el del cliente que hace lo que se espera de él. Todo lo que sale de ese recorrido sigue pendiente de decidir, y eso es lo que facturaron las dos revisiones anteriores. Un proveedor de seguridad vende esa lista de casos que nadie encargó: accesos entre cuentas, importes modificables, estados de error y eliminaciones.

Leer el código no basta

Replit añadió el 17 de agosto de 2026 pruebas de intrusión de caja negra, que atacan la aplicación desde su dirección pública sin leer el código, como complemento del análisis del propio código (replit.com, agosto de 2026). El proveedor clasifica sus verificaciones en tres niveles, el primero gratuito, y escribe que los hallazgos de los dos enfoques coinciden poco: cita un panel de administración sin protección, descubierto desde fuera y pasado por alto al leer el código. Ese anuncio vale sobre todo como una admisión útil para quien encarga software: pide ambos tipos de revisión, sea cual sea la herramienta que haya construido tu aplicación.

Lo que hace Félix y lo que no hace

En Maestro, la verificación forma parte del trabajo: Constance revisa el documento de requisitos antes de que empiece la construcción, Félix escribe las pruebas de cada etapa antes de que se construya y una etapa que falla la verificación vuelve a reparación. Este sistema detecta reglas olvidadas y regresiones, y obliga a escribir claramente quién tiene derecho a leer qué, como explicamos en la prueba de dos minutos sobre tus datos de clientes. Nadie en nuestro equipo ataca tu aplicación desde fuera una vez publicada. Tampoco estamos libres de nuestros propios defectos, y la clave que era visible en nuestro código lo recordó en agosto. Una revisión de seguridad encargada a un profesional sigue siendo un gasto que debes prever en tu presupuesto de lanzamiento.

La lista de la semana anterior

Cuatro rondas caben en cinco días. El lunes, los permisos: para cada pantalla y cada dato, escribe quién puede leer y quién puede modificar, y comprueba el comportamiento con dos cuentas de prueba. El martes, el dinero: repite una compra modificando lo que puedas modificar desde tu lado (cantidad, código de descuento, dirección de entrega) y observa si el importe final sigue siendo el del catálogo. El miércoles, la separación: asegúrate de que los visitantes de tu demostración y tus datos de prueba no escriban nada en la base que atiende a tus clientes reales. El jueves, los casos difíciles: cuenta eliminada, pago rechazado, exportación solicitada, contraseña perdida. El viernes, encarga una revisión a alguien externo y conserva el informe: desde el 11 de septiembre de 2026, tu software también tiene que rendir cuentas.