Se vende a farmacéuticas que compiten entre sí.

Dos cosas independientes. La primera es el filtro por organización que lleva cada consulta del API. La segunda es Row-Level Security de Postgres: las tablas del portal llevan políticas con ENABLE y FORCE ROW LEVEL SECURITY, y el usuario con el que se conecta la aplicación está creado como NOSUPERUSER NOBYPASSRLS — no puede saltárselas ni queriendo. Además el sesgo de las políticas es cerrado: si por un fallo no se fijara el contexto de organización, la consulta devuelve CERO filas en vez de devolverlas todas. Ninguna de las dos capas sustituye a la otra; la primera sin la segunda depende de la memoria de quien escribe cada consulta, y la segunda sin la primera depende de que nadie despliegue nunca con la conexión equivocada.

Porque un 403 dice «existe, pero no es tuyo», y esa diferencia basta para enumerar. Si unos identificadores contestaran 403 y otros 404, el patrón dibujaría el padrón de clientes — es decir, la lista de tus competidores que usan la misma herramienta. Se responde 404 siempre, y esa regla está escrita en la cabecera de cada router del API.

No. El usuario de base de datos del portal tiene GRANT SELECT — y nada más — sobre los esquemas donde vive el histórico de precios. El permiso de escritura completo lo tiene únicamente sobre el esquema propio del portal (usuarios, canastas, alertas, conversaciones). Son dos credenciales distintas: la del pipeline que captura, y la del portal que lee.

El token de acceso dura 15 minutos y no se puede renovar sin la cookie de refresco, que es httpOnly, Secure y SameSite=strict: el JavaScript de la página no puede leerla. Si el token de refresco viviera en localStorage, un solo XSS daría treinta días de sesión; si el de acceso fuera largo, expulsar a alguien sería imposible. Así, un XSS roba como mucho quince minutos y no puede renovarlos. Y si un token de refresco ya usado vuelve a aparecer, se revocan de golpe todas las sesiones vivas de esa persona.

Hay cinco roles. El analista construye —canastas, reglas de alerta— y el ejecutivo consume. La diferencia de fondo no es de permisos sino de visibilidad de datos: el ejecutivo no ve los agrupamientos de producto que están en revisión, porque toma decisiones de precio sobre lo que ve y un agrupamiento dudoso se convierte en un ajuste de precio equivocado. La captura de las cadenas no la puede lanzar ninguna organización: es global y golpea ocho APIs de farmacia, así que ese permiso lo tiene solo la administración de la plataforma.

No, contra la base de datos, en cada petición. Un token lleva los permisos con los que se emitió; si se leyeran de ahí, retirarle un rol a alguien tardaría hasta quince minutos en surtir efecto. Al re-derivarlos desde la base, un rol revocado deja de funcionar en la petición siguiente.

La monitorización de errores está configurada para no adjuntar información personal ni de negocio a ninguna traza: los precios y las canastas que vigilas son información competitiva y no deben salir del servidor. El chat sí manda tu pregunta al proveedor del modelo para poder responderla, y por eso el chat es un permiso separado que puedes no conceder. La documentación interactiva del API está apagada en producción — publicada sería un mapa completo del sistema para cualquiera.

Todavía no, y tampoco una auditoría externa. Lo decimos antes de que lo preguntes porque descubrirlo a mitad de una due diligence cuesta más que saberlo desde el principio. Si tu proceso de compra las exige, dilo en la demostración: te enseñamos con qué se cuenta hoy —aislamiento aplicado por la base de datos, cifrado en tránsito, sesiones cortas, registro de accesos— y qué está en camino.