Pasé tres años metiendo información sensible en Notion sin preguntarme ni una sola vez quién más podía verla. No configuración de seguridad, no auditoría de accesos, no nada. Notion era mi segunda cabeza y a la segunda cabeza no le hacés pentest.
Cuando vi el reporte que documenta cómo Notion expone los emails de todos los editores de cualquier página pública, mi primera reacción fue buscar cuántas páginas públicas tenía yo con colaboradores. Encontré más de las que esperaba. Pero lo que me molestó de verdad no fue el número — fue que en tres años nunca se me ocurrió pensar en Notion como superficie de ataque.
Y eso, como developer, es exactamente el tipo de error que no debería cometer.
Notion privacidad datos filtrados: qué está pasando exactamente
El problema es técnico y simple a la vez. Cuando tenés una página Notion con visibilidad pública ("Anyone with the link can view"), cualquier persona que acceda a esa página puede extraer los emails de todos los usuarios que alguna vez editaron ese documento.
No es un bug oscuro que requiere ingeniería inversa. Es una request a la API de Notion que devuelve los perfiles de los colaboradores, incluyendo direcciones de email, sin requerir autenticación adicional. Si la página es pública, los datos de sus editores también lo son.
El flujo es más o menos así:
# Una página pública de Notion expone esto en su API
# No necesitás estar autenticado — solo tener el link
curl 'https://www.notion.so/api/v3/loadPageChunk' \
-H 'Content-Type: application/json' \
--data '{
"pageId": "ID_DE_LA_PAGINA_PUBLICA",
"limit": 100,
"cursor": { "stack": [] },
"chunkNumber": 0,
"verticalColumns": false
}'
# En la respuesta vas a encontrar objetos de tipo "notion_user"
# con campos: email, name, profile_photo
# Para cada persona que haya editado esa página
# Sin importar si esa persona quería que su email fuera público
El vector de ataque práctico: alguien comparte una wiki pública de su empresa en Notion. Cualquiera que tenga el link puede enumerar todos los emails corporativos de quienes editaron esa wiki. Esos emails son el input perfecto para phishing dirigido, credential stuffing, o simplemente mapear el equipo de una organización.
No es ciencia ficción. Es una request HTTP.
Por qué esto me pegó diferente como developer
Hay una categoría de herramientas que los developers usamos sin aplicarles el mismo nivel de análisis que aplicamos a nuestro stack técnico. Las llamo herramientas de productividad, pero el nombre correcto sería puntos ciegos de seguridad.
Notion entra en esa categoría junto con Slack, Figma, Linear, y cualquier otra SaaS que usás para trabajar pero que no instalaste vos, no configuraste vos, y sobre la que asumís que "el proveedor se encarga".
El problema es que esa suposición es fundamentalmente incorrecta para cualquier herramienta que maneje datos de personas reales.
Yo escribí hace poco sobre cómo Emacs me dio algo que los agentes de IA todavía no pueden darme: confianza en mi entorno de configuración. La idea central era que entender las herramientas que usás cambia tu relación con ellas. Notion es exactamente el contraejemplo: lo usé sin entenderlo, y acá estamos.
En infraestructura aprendí esto a los golpes. Mi primera semana en un hosting Linux de producción tiré un servidor completo con un rm -rf mal apuntado. Desde ese día, antes de ejecutar cualquier cosa en prod, pienso dos veces. Pero esa disciplina mental la aplico al código y a la infra — no a la SaaS que uso para tomar notas.
Eso es un error de modelado. Estoy aplicando distintos estándares de análisis a sistemas que tienen el mismo nivel de acceso a información sensible.
// Así pienso en mi código:
interface SistemaConAccesoADatos {
requiereAuditoriaAccesos: boolean; // siempre true
requiereRevisionPermisos: boolean; // siempre true
requiereModeloDeAmenazas: boolean; // siempre true
}
// Así pienso (inconscientemente) en mis SaaS:
interface HerramientaDeProductividad {
requiereAuditoriaAccesos: boolean; // nunca me lo pregunto
requiereRevisionPermisos: boolean; // asumo que está bien
requiereModeloDeAmenazas: boolean; // para qué, si es solo Notion
}
// El problema: ambas interfaces manejan datos reales de personas reales
// La diferencia está solo en mi cabeza, no en la realidad del sistema
Esta inconsistencia es el problema de fondo. No Notion en particular.
Los errores concretos que probablemente estás cometiendo ahora mismo
1. Páginas públicas que olvidaste que son públicas
Notion te permite cambiar la visibilidad de una página con dos clicks. El problema es que también te permite olvidarte de haberlo hecho. Si en algún momento publicaste algo para compartir con alguien externo y no lo volviste a privado, esa página sigue ahí, exponiendo los emails de todo tu equipo.
Revisá tu workspace ahora: Settings → Members → Guest access. Después revisá cada página importante y verificá su configuración de visibilidad. No hay forma automática de hacer esto en el tier gratuito.
2. Asumir que "Anyone with the link" significa privacidad por obscuridad
Mucha gente piensa que compartir un link largo y aleatorio de Notion es seguro porque "nadie va a adivinar ese link". Eso es seguridad por obscuridad, y funciona exactamente hasta que alguien tiene el link — lo que pasa cada vez que lo mandás por email, Slack, o lo indexa Google porque lo pusiste en un lugar público.
La confiabilidad en sistemas no viene de la oscuridad sino del diseño explícito. Los trenes de Japón no son confiables porque los tracks son secretos — son confiables porque el sistema está diseñado para la confiabilidad. Aplicalo a tus herramientas.
3. No saber qué datos expone cada herramienta en cada estado de visibilidad
Este es el más importante y el más difícil. Para cada herramienta SaaS que usás con datos sensibles, ¿sabés exactamente qué información es accesible desde afuera cuando configurás visibilidad pública? Probablemente no. Yo no lo sabía de Notion.
El mínimo viable es leer la documentación de permisos de cada herramienta que toca datos de personas. No el tutorial de "cómo usar Notion" — la documentación de seguridad y permisos.
4. Mezclar información personal y laboral sin separación
Muchos developers tenemos un workspace de Notion donde coexisten notas personales, documentación de clientes, y recursos del equipo. Si alguna de esas páginas termina siendo pública, la superficie de exposición es enorme.
Separar workspaces por contexto de datos no es paranoia — es higiene básica de información. Lo mismo que aplicás cuando pensás en el overhead semántico de lo que incluís en un prompt: no todo tiene que estar en el mismo lugar.
# Auditoría mínima de páginas públicas en Notion
# No existe un comando oficial, pero podés hacer esto:
# 1. Ir a Settings & Members > Connections
# 2. Revisar cualquier integración con acceso a tu workspace
# 3. Para cada página importante, verificar Share settings:
# - "Only people invited" = privado ✓
# - "Anyone at [workspace]" = acceso interno ✓ (si confiás en tu org)
# - "Anyone with the link" = público ⚠️ revisar si es necesario
# - "Public on web" = indexable por Google ⚠️⚠️ revisá urgente
# 4. Buscar páginas con colaboradores externos (guests)
# Settings > Members > Guests — listar y auditar accesos
FAQ: Notion privacidad, datos filtrados y qué hacer
¿Notion ya solucionó este problema?
Al momento de escribir este post, el comportamiento documentado sigue siendo reproducible en páginas públicas. Notion no ha publicado un CVE ni un advisory de seguridad formal reconociendo esto como vulnerabilidad. La postura implícita parece ser que si una página es pública, la información de sus editores también lo es. Eso es discutible desde el punto de vista de privacidad — los editores no necesariamente consienten que su email sea público solo porque la página lo es.
¿Quién está en riesgo real?
Principalmente equipos que usan Notion para documentación pública (wikis, changelogs, bases de conocimiento) y que tienen múltiples colaboradores editando esas páginas. También cualquier persona que haya editado una página que después fue hecha pública sin su conocimiento. Si trabajás en una empresa que usa Notion y alguien en el equipo publicó documentación, tu email podría estar expuesto sin que vos lo supieras.
¿Es esto un bug o un feature?
Esa es la pregunta incómoda. Desde la perspectiva de Notion, mostrar quién editó qué es parte de la transparencia del producto. El problema es que la granularidad de control no acompaña esa decisión de diseño: no hay forma de decir "la página es pública pero los emails de los editores no". Es todo o nada, y eso es un problema de diseño de privacidad.
¿Qué hago con mis páginas públicas existentes?
Primer paso: auditarlas. Segundo paso: para cada página pública con colaboradores, preguntarte si realmente necesita ser pública o si "Anyone with the link" es suficiente (aunque tiene las limitaciones que describí). Tercer paso: para páginas que deben ser públicas y tienen contenido sensible de colaboradores, considerar publicar ese contenido en otro lugar (un blog, una wiki estática) donde controlás mejor qué datos se exponen.
¿Esto aplica a otras herramientas de productividad?
Sí, y ese es el punto más importante del post. Figma expone datos de colaboradores en archivos con link público. Google Docs tiene comportamientos similares dependiendo de la configuración. Confluence, Coda, y casi cualquier herramienta colaborativa tiene alguna versión de este problema. La diferencia es cuánto lo sabés antes de que alguien lo explote. Los agentes de IA que pasan todos tus tests sin ser correctos y las SaaS que exponenen datos sin que lo sepas tienen algo en común: confiás en ellos porque nunca te fallaron de forma visible todavía.
¿Notion es inseguro y no debería usarlo?
No. Notion es una herramienta útil con un problema de diseño de privacidad específico que hay que conocer. "No uses Notion" es la respuesta fácil y equivocada. La respuesta correcta es: usalo sabiendo cómo funciona, con visibilidad apropiada para cada tipo de contenido, y auditando periódicamente qué está expuesto. Lo mismo aplica a cualquier SaaS. El problema no es la herramienta — es la falta de modelo mental sobre lo que hace.
El problema real no es Notion
Esta historia tiene una lección que va mucho más allá de una configuración de privacidad.
Como developers, aplicamos rigor técnico asimétrico. Al código: revisión de seguridad, análisis estático, tests, code review. A la infra: modelo de amenazas, principio de menor privilegio, auditoría de accesos. A las herramientas SaaS que usamos todos los días: nada.
Eso es una inconsistencia que cuesta cara. No siempre de forma dramática — a veces cuesta la privacidad de los colaboradores de una wiki que olvidaste que era pública.
Brunost existe como lenguaje de programación en Nynorsk y eso dice algo sobre quién decide qué es legible y qué no. En el mismo sentido, el hecho de que casi ningún developer audite sus herramientas de productividad dice algo sobre qué decidimos que merece atención técnica y qué no. Esa decisión implícita tiene consecuencias reales.
Lo que voy a hacer distinto desde ahora:
- Auditoría trimestral de páginas públicas en Notion — no como proceso de seguridad formal, sino como higiene básica
- Documentación interna vs. externa separada — si algo es para consumo público, va a una herramienta diseñada para eso, no a Notion con visibilidad pública
- Antes de hacer pública cualquier página colaborativa, preguntarme explícitamente qué datos de colaboradores estoy exponiendo
- Extender el modelo de amenazas que aplico a mi código e infra a las herramientas que uso cotidianamente
Nunca pensé en Notion como superficie de ataque. Ahora sí. Eso no hace a Notion peligroso — me hace a mí más cuidadoso. Que es exactamente donde debería estar.
Revisá tus páginas públicas. Ahora.
Este artículo fue publicado originalmente en juanchi.dev
Top comments (0)