No se tiene ninguna certificación SOC 2, ISO 27001 ni de otro tipo.
Elige un producto
Hosting webSitios web y WordPress con un plan de precio fijoCloudDespliega apps, API y bases de datos desde Git o DockerAI BuilderCrea y modifica sitios y apps con IAAñade a cualquier proyecto
Dominios y correoBases de datosWordPress gestionadoEntornos para agentesMigracionesDesarrolladores
Todo sobre IADesarrolladoresMCP para asistentes de IADocumentaciónSeguridadEstadoHostingsurge
PreciosIniciar sesiónSeguridad
Aislamiento y trabajo verificado, por diseño.
Esta página describe cómo está construida realmente la plataforma de Hostingsurge: el límite de la base de datos, el límite de las sesiones, el sandbox de compilación y la ruta de los pagos. No menciona ninguna certificación ni auditoría, porque no existe ninguna.
Aislamiento de inquilinos en la base de datos
El aislamiento se aplica donde viven los datos, no solo en el código de la aplicación.
- Cada tabla sensible a los inquilinos tiene una organización propietaria (organization_id o un límite de inquilino equivalente) con propiedad compuesta hasta los proyectos.
- La seguridad a nivel de fila (row-level security) es obligatoria para las tablas de inquilinos, y los roles de ejecución son restringidos: el rol de identidad no puede leer datos de proyectos ni de monederos, y el límite de las solicitudes rechaza los roles administrativos de PostgreSQL, los de superusuario y los que tienen permisos a nivel de archivo o de servidor.
- El contexto del inquilino se establece en cada transacción. Un identificador que llega desde un navegador es una solicitud, nunca una autorización.
- Las escrituras protegidas pasan por funciones que verifican de forma independiente la sesión y la autoridad vigente, y las escrituras directas de los roles de la aplicación están revocadas para esas tablas.
Sesiones y autoridad vigente
La autenticación se comprueba a la entrada, y la autoridad se vuelve a comprobar en el momento en que se usa.
- Las cookies de sesión son HttpOnly y SameSite=Lax, con el prefijo __Host- en producción, y cada solicitud asocia la sesión a un usuario y a un inquilino antes de que ocurra cualquier otra cosa.
- Las solicitudes del navegador que modifican datos deben venir del origen configurado, y los cuerpos de las solicitudes están limitados (application/json, 16 KiB, plazo de cinco segundos).
- Los cambios sensibles —cambios de MFA, emisión de credenciales, compras, cambios de plan— requieren una autenticación reciente en lugar de una sesión de larga duración.
- La MFA es TOTP con códigos de recuperación de un solo uso. Los tokens y los códigos se consumen de forma atómica, así que dos usos simultáneos no pueden tener éxito a la vez.
Credenciales y aprobaciones de operaciones
Una credencial es un permiso acotado y revocable, no una llave permanente a la plataforma.
- Las credenciales de API y MCP se almacenan con hash, están vinculadas a una organización, una marca y un proyecto, tienen ámbitos explícitos y una vida útil limitada, y se muestran exactamente una vez.
- Quitar a alguien de un equipo revoca permanentemente sus credenciales, y un restablecimiento de contraseña invalida las credenciales emitidas antes.
- Las acciones sensibles y facturables requieren una aprobación de corta duración vinculada al usuario, la organización, el proyecto, la acción exacta, el destino y el digest canónico de la entrada.
- El consumo de la aprobación, la admisión del trabajo, la reserva de créditos, la auditoría y el registro en el outbox se confirman en una única transacción; si el callback de confianza falla, se revierte toda la admisión. Los cambios de rol o de membresía revocan permanentemente las aprobaciones pendientes.
Las compilaciones se ejecutan aisladas
El código de los clientes y el generado por IA se tratan como no confiables, porque no lo son.
- Las compilaciones se ejecutan en un contenedor temporal sobre una imagen base mínima, con la red desactivada, memoria y CPU limitadas, un límite de procesos, un sistema de archivos raíz de solo lectura, un montaje temporal noexec acotado, sin socket de Docker y sin credenciales de producción, bajo un tiempo máximo de ejecución.
- Un artefacto debe superar la verificación de digest y de tamaño y escribirse a través de un almacén atómico —escribir, hacer flush, releer, renombrar de forma atómica y volver a releer— antes de que se registre un recibo de compilación. Por eso, un fallo nunca puede dejar un estado listo sin bytes persistidos.
- Los recibos de compilación y de artefactos son de solo anexado (append-only); una actualización o un borrado provoca un error de inmutabilidad.
- Un worker mantiene un arrendamiento con fencing, lo renueva mientras trabaja y se detiene si pierde la titularidad. Los límites de código fuente y de archivo comprimido (1000 entradas, 256 KB por archivo, 16 MB en total) se aplican tanto a la entrada como a la salida.
- El contenido de los archivos se entrega al navegador como texto escapado: el marcado dentro de un archivo guardado permanece inerte y nunca se ejecuta.
Pagos verificados a partir de eventos firmados
El dinero solo cambia cuando el proveedor lo indica, y la plataforma puede demostrarlo.
- Los webhooks de pago se verifican con una comprobación real de la firma sobre el cuerpo bruto y acotado de la solicitud, con controles de repetición y de tiempo y un ámbito exacto de cuenta y de modo test/live. El endpoint solo confirma una recepción persistida.
- Los créditos solo se convierten en saldo después de verificar el pago con el proveedor —factura, payment intent y cargo— y cada concesión se aplica exactamente una vez.
- Los precios nunca se toman de un navegador: los importes y las unidades de crédito proceden de un catálogo del servidor, y se rechaza cualquier precio que no coincida con el producto, el importe, la moneda y el ciclo esperados.
Alojamiento en la UE y endurecimiento documentado
Lo que es cierto hoy, incluido lo que aún no está terminado.
- Los servidores están en la UE y los gestiona la plataforma. Los clientes nunca reciben un panel de control del proveedor; todo pasa por Hostingsurge.
- En el servidor de producción se instalaron las actualizaciones pendientes del sistema operativo (incluidas las de seguridad), se activó el cortafuegos conservando SSH, HTTP, HTTPS y HTTP/3, y la interfaz de administración del proxy inverso se restringió a localhost y se verificó tras un reinicio.
- El tráfico termina mediante TLS y un proxy reforzado; las interfaces de administración no están expuestas a internet.
- La base de datos de control se respalda cada 24 horas en almacenamiento del mismo servidor y se conserva durante 14 días. La copia externa cifrada ya está construida, pero su bucket de almacenamiento aún no está conectado, así que por ahora las copias de seguridad se quedan en el servidor; se indica aquí en vez de dejarlo implícito.
Lo que esta página no afirma
Dicho sin rodeos, porque una página de seguridad que exagera es peor que no tener ninguna.
No se ha realizado ninguna auditoría de seguridad independiente.
No existe ningún informe de pruebas de penetración de terceros.
No se ofrece ningún SLA de disponibilidad ni ningún programa de bug bounty.
Todavía no se ha publicado ninguna dirección para notificar problemas de seguridad. Hasta que exista, un hallazgo no tiene un canal confirmado, y esta página indicará uno cuando exista.
Lee los límites y luego decide.
La página para desarrolladores documenta los endpoints reales y su autenticación. La documentación indica, módulo por módulo, qué está implementado.
Todo lo anterior describe la versión actual. En ningún lugar de este sitio se afirma tener una certificación, una auditoría o un SLA.