Cita a partir de mañana
Agendar revisión
99 €
Elegimos hueco, miro tu app con calma y te digo qué pasa y cómo se arregla.
- Sesión de trabajo en directo contigo
- Diagnóstico del error y del riesgo real
- Te quedas con el arreglo aplicado
Mis source maps son públicos: se ve todo mi código
Al construir tu app, el código se comprime hasta quedar ilegible. Los source maps son unos ficheros que deshacen esa compresión para poder depurar, y contienen tu código tal y como lo escribiste, con nombres y comentarios. Se han publicado junto a la app, así que cualquiera puede descargarlos y leerlo entero.
Compruébalo en tu app ahora, gratis
Esto no da la cara solo: tu app funciona igual de bien esté abierta o cerrada. La única forma de saberlo es mirar.
Solo leemos lo que tu app ya le entrega a cualquier visitante.
Por qué te pasa
Porque en la mayoría de las herramientas es el comportamiento por defecto, o lo era cuando se generó tu proyecto. Nadie toma la decisión de publicarlos: se publican salvo que alguien diga lo contrario, y nadie dice lo contrario porque nadie sabe que existen.
Que sea el comportamiento por defecto tiene su lógica: son enormemente útiles para entender un error en producción. El problema no es que existan, es que sean descargables por cualquiera en vez de quedarse en un servicio de seguimiento de errores.
Lo que este error no significa
- No es una puerta abierta a tus datos. Nadie entra en tu base de datos por esto. Es un plano de tu casa, no una llave.
- No significa que tu app sea insegura por sí sola. Si tus permisos están bien puestos, que se lea tu código no cambia nada: la seguridad de verdad nunca puede depender de que nadie vea cómo funciona algo.
- No es urgente como lo son una clave o una tabla abierta. Es de las cosas que conviene cerrar, no de las que hay que cerrar esta noche.
Arréglalo tú, gratis
Es de los arreglos más sencillos que hay, una línea de configuración y un despliegue. Lo que sí merece un rato es la pregunta que viene detrás: qué se ha podido leer mientras tanto.
- 1Localiza el fichero de configuración de tu proyecto. En apps hechas con Vite, que es el caso de casi todo lo generado con Lovable o Bolt, es vite.config. En Next.js, next.config.
- 2Desactiva la generación de mapas para la compilación de producción. En Vite es la opción sourcemap dentro de build, puesta a falso. En Next.js es productionBrowserSourceMaps, que debe quedar en falso o directamente no estar.
- 3Vuelve a desplegar y comprueba el resultado: abre uno de tus ficheros JS publicados añadiendo .map al final de su dirección. Si ahora da un error de no encontrado, está cerrado.
- 4Y ahora la parte que de verdad importa: si tu código llevaba dentro alguna clave, una dirección interna o lógica de permisos, dalo por leído y trátalo en consecuencia. Los ficheros han estado descargables y no hay forma de saber quién los cogió.
- 5Aprovecha para pasar el escáner de arriba otra vez. Si había una clave dentro de ese código, aparecerá, y ese sí es el problema urgente.
Y esto para la parte de código
Pégaselo tal cual al agente que escribió tu app. Está redactado para que te diga lo que ha hecho, no solo para que lo haga.
Prompt para pegarle a tu agente
Mi app está publicando los source maps y cualquiera puede reconstruir mi código original. Necesito que hagas esto: 1. Localiza el fichero de configuración de compilación del proyecto y desactiva la generación de source maps solo para producción, dejándolos activos en desarrollo. 2. Revisa el código en busca de cosas que no deberían leerse aunque el código sea legible: claves escritas directamente, direcciones de servicios internos, comentarios con credenciales o con datos de clientes. Dime lo que encuentres sin pegarme los valores. 3. Comprueba si hay lógica de permisos que se ejecute solo en el navegador. Si la hay, dímelo: si esa lógica era lo único que protegía algo, ahora es pública y hay que moverla al servidor. 4. Confírmame qué fichero has cambiado y qué opción exacta, para que yo lo verifique.
Si el escáner ha encontrado algo, no lo toques con prisa
Cerrar una puerta abierta tiene un orden: primero se corta el acceso, después se comprueba en los registros si alguien entró, y solo entonces se despliega. Hacerlo al revés deja la app caída y borra el rastro de lo que pasó. Si prefieres no hacerlo solo, elige cuándo lo hacemos.
Hoy, en cola prioritaria
Rescate exprés
199 €
Entras en la cola de hoy. Reservas hueco y lo dejamos resuelto en el día.
- Hueco el mismo día
- Prioridad sobre las revisiones agendadas
- Mismo trabajo, antes
Quién lo arregla
Marc Sala
IT Manager
- Analista de ciberseguridad certificado por Google
No es un rating anónimo de un marketplace: es la persona que va a entrar en tu app. Reviso el código, encuentro qué falla y lo arreglo contigo delante.
Errores que suelen venir con este
- La clave service_role de Supabase está en el código públicoSupabase te da dos llaves. Una es pública y va en el navegador a propósito. La otra, la service_role, se salta todas las reglas de seguridad de tu base de datos y solo debe vivir en un servidor. La segunda ha acabado dentro del código que se descarga cualquiera que visite tu web.
- La lógica de permisos deja entrar a quien no debeTu app decide quién puede ver o hacer cada cosa en el código que corre en el navegador del visitante. El problema es que ese código está en su ordenador, no en el tuyo: puede leerlo, cambiarlo y saltárselo. Ocultar un botón no impide la acción que había detrás.
- Puse el prefijo VITE_ o NEXT_PUBLIC_ a un secreto y se publicóEsos prefijos no son un formalismo del nombre: son una instrucción. Le dicen a la herramienta que construye tu app que esa variable debe copiarse dentro del código que se descarga el navegador. Ponerle ese prefijo a un secreto es, literalmente, pedir que se publique.