Modo de mantenimiento con acceso de administrador: mantén el sitio seguro durante las reparaciones

Por qué el modo de mantenimiento necesita más que una página en blanco

Una simple página de “Estamos en mantenimiento” parece segura, pero a menudo crea nuevos problemas durante una reparación en vivo. Los usuarios siguen reintentando acciones, los jobs en segundo plano siguen ejecutándose y algunas partes de la app pueden aceptar cambios. Así es como se llega a la corrupción de datos: pedidos a medias, registros duplicados o actualizaciones que solo llegan a algunas tablas.

El fallo habitual no es un gran colapso, sino actualizaciones parciales. Un usuario aún puede enviar un formulario, una llamada de API puede seguir escribiendo en la base de datos o un webhook puede seguir importando datos mientras cambias la lógica. El sitio parece “caído”, pero el sistema sigue cambiando por debajo.

Un apagado total también puede perjudicar a personas reales. Los clientes pueden necesitar recibos, detalles de reservas o una actualización de estado. Soporte puede necesitar consultar una cuenta para responder un ticket. Si bloqueas todo, pierdes la capacidad de verificar qué está pasando y puedes ralentizar la reparación porque no puedes comprobar el comportamiento en producción de forma segura.

El modo de mantenimiento “solo lectura” significa que la app sigue permitiendo ver información, pero rechaza cualquier cosa que cambie el estado. Las páginas pueden cargarse, las búsquedas pueden funcionar, los paneles pueden mostrar datos, pero registros, pagos, ediciones de perfil, subidas y cambios de admin quedan bloqueados. La clave es la aplicación de la regla en el servidor, no solo esconder botones.

El objetivo es simple: proteger tus datos mientras mantienes lo esencial accesible. Mantén el sitio legible, los logs y la monitorización visibles, y una vía estrecha para admins y soporte abierta para que las reparaciones ocurran sin empeorar las cosas.

Decide qué se mantiene disponible y qué debe bloquearse

Antes de activar el modo de mantenimiento, decide en una frase qué significa “seguro” para tu app. Ejemplo: “Durante mantenimiento, cualquiera puede ver páginas públicas y de solo lectura, pero nadie puede cambiar datos a menos que sea un administrador en una lista aprobada.” Esa frase será la regla para cada página, endpoint y herramienta.

Empieza por lo que puede permanecer público sin crear riesgo. Normalmente son páginas que no escriben en tu base de datos y no exponen datos privados: una página de estado, páginas de marketing, docs/ayuda, precios y vistas de solo lectura como un catálogo público o blog. Áreas de usuario autenticado en solo lectura (como un resumen de cuenta) también pueden estar bien, siempre que no desencadenen actualizaciones en segundo plano.

Después, bloquea las acciones con más probabilidad de crear datos malos o problemas de seguridad mientras arreglas producción. Escrituras “riesgosas” típicas incluyen:

• Checkout, pagos, suscripciones
• Edición de perfil, cambios de contraseña y correo
• Subidas de archivos, importaciones, acciones masivas
• Cualquier cosa que cree, actualice o elimine registros (incluidas herramientas de admin)
• Webhooks que escriben datos (pagos, correo, CRM)

Luego decide qué necesita soporte durante la interrupción. Soporte suele necesitar acceso de lectura tras iniciar sesión para responder tickets. Mantén esas rutas disponibles, pero restringe las partes que cambian datos. Por ejemplo, soporte puede buscar un pedido, pero no puede reembolsar, reenviar o editar direcciones hasta que estés estable.

Una forma concreta de pensar en el modo solo lectura es una tienda: la gente puede navegar productos y ver su carrito, pero no puede hacer un pedido ni cambiar la información de envío. Los administradores pueden iniciar sesión para diagnosticar, pero solo los admins aprobados pueden realizar escrituras.

Elige un enfoque para acceso de admin y soporte

Cuando activas mantenimiento con acceso de administrador, la meta es simple: los usuarios regulares permanecen seguros, mientras personas de confianza siguen pudiendo entrar y arreglar el problema. Elige la apertura más pequeña que aún te permita trabajar.

Opción A: Permitir admins por rol tras iniciar sesión

Esta es la opción por defecto más segura para la mayoría de apps. Todos ven el modo de mantenimiento hasta que inician sesión; entonces compruebas su rol (admin, owner, engineer) y les permites el acceso.

Funciona bien porque mantiene tu sitio privado por defecto y deja un rastro de auditoría (quién inició sesión, qué hizo). El requisito es que tu login y las comprobaciones de rol ya sean fiables. Si la autenticación forma parte de lo que está roto, necesitas un respaldo.

Opción B: Allowlist de IP o acceso temporal

Si el inicio de sesión falla, puedes usar una puerta más simple:

• Allowlist de IP (IP de oficina, salida de VPN): buen control, pero la gente se queda fuera en móvil o desde casa a menos que usen VPN.
• Token de acceso temporal (código de un solo uso) o ruta secreta: rápido, pero arriesgado si se filtra en chats, historial del navegador o capturas de pantalla.

Si usas un token o ruta secreta, límitalo en el tiempo (horas, no días), rótalos después de usarlos y registra cada petición que los use.

El acceso de soporte no debe equivaler a admin completo. Crea un rol de soporte que pueda ver páginas e inspeccionar registros de usuarios, pero que no pueda cambiar facturación, permisos o configuración.

Mapea todas las escrituras riesgosas antes de activar el modo

Antes de habilitar mantenimiento con acceso de admin, aclara una cosa: qué puede seguir cambiando datos. Si te olvidas de una ruta de escritura, puedes acabar con actualizaciones parciales, pagos atascados o “cambios misteriosos” durante la reparación.

Lista cada lugar donde tu app puede crear, actualizar o borrar algo. Piensa más allá de formularios obvios. APIs, clientes móviles, herramientas internas y paneles de administración suelen golpear endpoints distintos, y todos cuentan.

Un inventario rápido es escanear rutas por POST, PUT/PATCH y DELETE, y luego comprobar con logs. Concéntrate en áreas de alto impacto:

• Auth y cuentas: registro, restablecer contraseña, cambios de rol
• Dinero: checkout, suscripciones, reembolsos, facturación
• Contenido: publicar/despublicar, ediciones, subidas
• Acciones masivas y admin: ediciones masivas, borrados, suplantación
• Integraciones: botones de “sync now” y funciones de push de datos

También busca escrituras que ocurren sin que un usuario haga clic. Workers en background, colas, cron jobs y tareas programadas pueden seguir modificando registros aunque la UI esté “pausada”. Jobs como “reintentar pagos fallidos”, “enviar resúmenes”, “recalcular estadísticas” y “sincronizar desde CRM” suelen necesitar pausarse o forzarse a modo sin escritura.

Los webhooks de terceros son otra sorpresa común. Proveedores de pagos, herramientas de correo y servicios de formularios pueden llamar tu app en cualquier momento y disparar escrituras. Anota cada webhook entrante y qué cambia para poder devolver una respuesta segura (o dejar de procesarlos) durante el mantenimiento.

Paso a paso: añadir una puerta de mantenimiento sin romper el acceso

Empieza con una regla simple: el modo de mantenimiento debe controlarse con un único interruptor. Puede ser una variable de entorno, un valor de configuración en la base de datos o una feature flag. Manténlo simple y obvio para poder activarlo o desactivarlo rápido.

Pon la “puerta” lo más temprano posible en el flujo de la petición (middleware, filtro global o el primer handler del servidor). Si añades comprobaciones en páginas sueltas, te perderás endpoints.

Un flujo práctico que funciona para la mayoría de apps:

• Leer el interruptor de mantenimiento al inicio de la petición.
• Si mantenimiento está desactivado, continuar normalmente.
• Si mantenimiento está activado, comprobar un bypass de admin/soporte.
• Si no hay bypass, permitir solo peticiones seguras de solo lectura.
• En caso contrario, bloquear y devolver una respuesta clara de mantenimiento.

Para acceso de solo lectura, sé estricto. Normalmente es más seguro permitir solo GET y HEAD, más una pequeña allowlist de endpoints verdaderamente seguros (como una página pública de estado). Trata cualquier cosa que cambie estado como riesgosa, incluso si parece inofensiva.

Para el bypass, no te fíes de una sola señal débil. Una configuración más segura combina al menos dos comprobaciones: (1) el usuario está autenticado y tiene el rol correcto, y (2) la petición viene de un camino de confianza (dominio admin, IP allowlisteada, VPN o un header con token de soporte de un solo uso). Esto reduce la posibilidad de que una cookie filtrada o una URL adivinada dé acceso de escritura durante una ventana frágil.

Cuando bloquees una petición, devuelve algo consistente. Para páginas web, muestra un mensaje amigable y un tiempo estimado. Para APIs, devuelve 503 con un pequeño cuerpo JSON que indique que el mantenimiento está activo y la petición fue bloqueada.

Paso a paso: parar escrituras de forma segura (no solo en la UI)

Deshabilitar botones ayuda, pero no detiene las escrituras reales. Durante el modo mantenimiento con acceso de admin, asume que alguien (o algo) aún puede golpear tu API directamente, reintentar una petición antigua o disparar un job en background. Quieres que las escrituras estén bloqueadas en más de un lugar.

1) Bloquear escrituras en la app y la API

Empieza por la capa de cara al usuario y luego haz que la medida se aplique en el servidor.

• Deshabilita formularios y acciones principales (checkout, edición de perfil, publicar, subidas).
• Añade una comprobación server-side que rechace métodos de escritura (POST, PUT, PATCH, DELETE) a menos que la petición esté explícitamente permitida.
• Protege operaciones sensibles (restablecer contraseña, cambios de rol, reembolsos) con confirmaciones extra durante el mantenimiento.
• Devuelve un error claro para que soporte pueda explicar lo ocurrido sin adivinar.

Mantén páginas de solo lectura funcionando donde sea posible: páginas de producto, docs, estado y vistas de cuenta que no cambien datos.

2) Detener las “escrituras invisibles”: jobs, webhooks y reintentos

La mayoría del daño sorpresa viene de sistemas que siguen funcionando después de que pausaste la UI.

Pausa o vacía workers en background que creen registros, envíen correos, cobren tarjetas o sincronicen con terceros. Para webhooks y eventos entrantes, elige un comportamiento seguro: encolarlos para más tarde o rechazarlos con una respuesta de mantenimiento para que el emisor reintente después. En cualquier caso, registra lo que descartaste o retrasaste.

Si puedes, añade también protección a nivel de base de datos: marcar tablas como solo lectura, añadir constraints o envolver actualizaciones clave en transacciones que fallen rápido cuando el mantenimiento está activo.

Mensajería al usuario que reduce tickets y confusión

Un buen mensaje de mantenimiento hace dos cosas: protege tus datos y dice a la gente qué hacer a continuación. Si lo único que ven los usuarios es un vago “en mantenimiento”, seguirán reintentando, generando tickets y a veces empeorando el problema.

Mantén el mensaje corto y específico. Di qué no está disponible (checkout, publicar, editar perfil), qué sigue funcionando (navegar, búsqueda, leer docs) y cuándo volver a intentarlo. Si no tienes una hora exacta, da un rango y comprométete a actualizarlo.

Si usas mantenimiento con acceso de admin, dilo sin dar detalles sensibles. Para usuarios regulares, muestra una página simple indicando la acción bloqueada. Para admins y soporte, deja el login disponible si ese es tu plan y muestra un banner obvio en el área de administración: “Modo de mantenimiento ACTIVADO.” Ese banner evita que compañeros prueben cambios pensando que el sitio está en producción.

Usa una respuesta HTTP consistente para acciones bloqueadas. Un 503 Service Unavailable es la elección habitual y va bien con un header Retry-After si puedes establecerlo.

Frases claras que reducen tickets:

• Qué está pausado: “Pagos y nuevos registros están temporalmente deshabilitados.”
• Qué sigue funcionando: “Aún puedes ver páginas existentes y descargar facturas.”
• Cuándo reintentar: “Por favor, vuelve a intentarlo después de las 15:00 UTC (actualizaremos este mensaje si cambia).”
• Ruta de soporte: “Si esto bloquea trabajo urgente, contacta con soporte indicando el correo de tu cuenta.”

Errores comunes que causan bloqueos o filtraciones de datos

La mayoría de las peores situaciones ocurren porque el modo de mantenimiento se trata como un simple “mostrar un banner”. Si necesitas mantenimiento con acceso de administrador, los detalles importan. Un guard mal puesto puede dejar fuera a las únicas personas que pueden arreglar producción.

Bloqueos: cuando el bypass no puede llegar al login

Una trampa clásica es proteger la página de login (o el callback de SSO) con la misma puerta de mantenimiento que el resto del sitio. Rediruyes a una página bloqueada, pero esa página requiere una sesión para verse. Ahora los admins no pueden iniciar sesión para crear la sesión.

Otro bloqueo ocurre cuando el bypass depende de datos a los que no puedes acceder durante el mantenimiento, como una comprobación en la base de datos que falla mientras reparas migraciones.

Filtraciones: cuando “solo lectura” no es realmente seguro

Aunque la UI desactive botones, las escrituras pueden seguir viniendo por rutas que olvidaste proteger. Fallos habituales:

• Jobs en background, tareas cron o workers siguen corriendo y actualizando registros.
• Webhooks e integraciones siguen llamando endpoints que aún aceptan escrituras.
• Una cookie de bypass o un parámetro en la URL funciona para cualquiera, no solo para personal confiable.
• El cache sirve páginas personalizadas a la persona equivocada tras cambiar reglas de acceso.
• El interruptor está hardcodeado o desplegado sin una rápida reversión.

Ejemplo: marcas el sitio como “solo lectura”, pero los webhooks de Stripe siguen marcando facturas como pagadas, un job recalcula saldos y una página cacheada de “Mi cuenta” se sirve a otro usuario porque la clave de cache no incluía el ID de usuario.

Unos patrones más seguros reducen el riesgo rápidamente:

• Pon la puerta en el servidor, no solo en el frontend.
• Pausa workers y maneja webhooks explícitamente durante mantenimiento.
• Haz que el bypass sea por roles, limitado en el tiempo y registrado.
• Revisa reglas de cache para cualquier página que pueda contener datos privados.

Lista de comprobación rápida antes de activar mantenimiento

Antes de activar el interruptor, haz una prueba rápida en una ventana privada (o en una copia de staging). Los usuarios normales no deberían poder cambiar datos, pero admins y soporte deberían poder entrar y diagnosticar.

Lista de comprobación para el modo mantenimiento con acceso de admin:

• Confirma que el toggle funciona en ambos sentidos. Activa mantenimiento, refresca, luego desactiva y refresca de nuevo.
• Prueba la entrada de admin y soporte de punta a punta. Asegúrate de que el bypass funciona tras iniciar sesión y que pueden llegar a las herramientas que usan.
• Bloquea escrituras en el backend, no solo en la UI. Intenta registro, restablecer contraseña, checkout y guardar perfil. Verifica que fallen en el servidor aunque el endpoint sea llamado directamente.
• Decide qué hacer con trabajo en background. Pausa tareas programadas que modifiquen datos. Haz que los webhooks se pongan en cola de forma segura o que devuelvan una respuesta clara de “temporalmente no disponible”.
• Verifica que el mensaje al usuario sea exacto: qué sigue funcionando, qué está pausado y cuándo volver a comprobar.

Haz una última prueba de “oops”: cierra sesión, borra cookies y repite un intento de escritura desde una cuenta normal. Muchas interrupciones empeoran porque una ruta de escritura oculta (autosave, webhook, job) siguió corriendo.

Ejemplo: mantener el sitio legible mientras reparas producción

Son las 14:15 en un día concurrido y notas un patrón: algunos checkouts terminan, pero los registros de pedidos están mal formados. Algunos clientes son cobrados, pero sus pedidos muestran líneas faltantes. Dejar el sitio abierto por completo arriesga corromper aún más datos.

Activan el modo de mantenimiento con acceso de admin, pero no tiran todo abajo. Los compradores pueden seguir navegando productos y leyendo FAQs. También pueden ver pedidos pasados, lo que reduce pánico y tickets duplicados. Lo que se bloquea es cualquier cosa que cree o cambie datos.

Qué implica el interruptor de solo lectura en la práctica:

• Añadir al carrito y checkout quedan bloqueados server-side
• Ediciones de cuenta (dirección, contraseña) quedan bloqueadas
• Aplicar códigos promocionales y canjear tarjetas regalo quedan bloqueados
• Historial de pedidos y detalle de pedidos siguen disponibles
• Páginas de producto y búsqueda siguen disponibles

Los admins siguen iniciando sesión con normalidad. Pueden acceder a logs, dashboards de errores y la vista de pedidos en admin para localizar el momento en que los pedidos empezaron a fallar. Mientras el público ve páginas en solo lectura, un admin aplica un hotfix y hace una comprobación rápida con algunos pedidos de prueba.

Soporte también mantiene acceso, pero con permisos más limitados. Pueden buscar usuarios, confirmar si un cargo se realizó y ver estado de pedidos. No pueden editar cuentas ni crear reembolsos mientras el sistema es inestable.

Una vez desplegada la corrección, realiza una verificación corta: procesa pagos de prueba (o lo que permita tu setup), confirma que totales y líneas de pedido coinciden y que los eventos downstream se disparan como es debido. Solo entonces vuelve a activar las escrituras.

Pasos siguientes y cuándo pedir ayuda

Si necesitas mantenimiento con acceso de admin, mantén el primer despliegue pequeño. Bloquea primero las escrituras de mayor riesgo: pagos, restablecimiento de contraseña, cambios en cuentas, ajustes de admin y cualquier cosa que dispare emails o webhooks. Una vez seguros esos, expande a acciones menos críticas.

Escribe un runbook corto antes de activar el interruptor. No tiene que ser sofisticado, pero sí lo bastante claro para que alguien adormilado a las 2 a.m. pueda seguirlo:

• Quién puede activar y desactivar el modo de mantenimiento
• Cómo verificar que funciona (como usuario normal y como admin)
• Cómo confirmar que las escrituras están realmente bloqueadas (no solo ocultas)
• Qué hacer si los admins quedan bloqueados
• Cómo revertir de forma segura

Pide ayuda cuando se cumpla cualquiera de estas condiciones: no puedes listar con confianza todos los endpoints de escritura, tienes múltiples clientes (web y móvil) golpeando el mismo backend, o ves problemas de seguridad como secretos expuestos o riesgos de inyección SQL durante la caída.

Si heredaste una app generada por IA y las rutas de escritura o las comprobaciones de roles están enredadas, una auditoría focalizada puede ahorrar tiempo. FixMyMess (fixmymess.ai) se centra en diagnosticar y reparar bases de código creadas por IA, incluyendo trazar rutas de escritura, reforzar puertas de roles y asegurar antes de reabrir escrituras.