1. Pregunta y contexto
Un producto necesita compartir una factura, un archivo o una acción de un solo uso. El propio enlace contiene la capacidad de acceso (capability), por lo que el servidor no necesita identificar primero una cuenta que haya iniciado sesión. El enfoque de la entrevista es cuándo es razonable este modelo y cómo gestionar los enlaces que se copian, se registran en logs o se reenvían.
2. Lo que evalúa el entrevistador
- Si distingue entre capability URLs, sesiones de inicio de sesión y modelos de confianza de bearer tokens de OAuth.
- Si su modelo de amenazas incluye la filtración de URLs a través de logs, historial, analíticas, referrers y capturas de pantalla.
- Si diseña expiraciones cortas, mínimo privilegio, un solo uso o vinculación de destinatarios (audience binding).
- Si admite la revocación por enlace, la revocación masiva y la auditabilidad en lugar de limitarse a rotar una clave global.
La guía de capability URLs del W3C indica que el acceso otorgado debe poder revocarse si una capability URL se filtra. OWASP aconseja explícitamente no incluir contraseñas, claves de API o tokens de seguridad en las URLs, por lo que una capability URL necesita un límite de riesgo claro y controles compensatorios.
3. Preguntas de clarificación antes de responder
- ¿El recurso es público, de baja sensibilidad o es personal, financiero o regulado?
- ¿El visitante debe iniciar sesión y el enlace cruzará los límites de la organización?
- ¿El acceso es una descarga de una sola vez, una ventana corta o una colaboración de larga duración?
- Tras una filtración, ¿se debe revocar un enlace, un usuario o todo el recurso?
4. Estructura de respuesta de 30 segundos
Utilice idoneidad, token, filtración, revocación y alternativa.
Utilizaría una capability URL solo para accesos de baja frecuencia y auditables donde la simple posesión sea aceptable, acotándola a un solo recurso y a una ventana corta. El token debe tener alta entropía y ser impredecible; el servidor almacena únicamente un hash y registra la creación, el uso y la revocación. Establecería Referrer-Policy: no-referrer y lo mantendría fuera de los logs y de las analíticas de terceros. Los recursos sensibles deberían usar autorización autenticada, limitando la capability URL a una invitación de un solo uso o a una credencial de descarga.
5. Análisis detallado paso a paso
Paso 1: Elegir el modelo de confianza adecuado
Una capability URL implica que la posesión otorga autoridad; no demuestra la identidad de una cuenta. Se adapta a la compartición de baja sensibilidad, descargas únicas o invitaciones sin registro. No es adecuada para membresías de granularidad fina, requisitos de auditoría a largo plazo o una garantía de identidad sólida. Para un bearer token de OAuth, prefiera el encabezado Authorization; la RFC 6750 menciona el parámetro de consulta de URI como un transporte posible pero de mayor riesgo.
Paso 2: Minimizar la capacidad
Vincule el token a un recurso, una acción y una audiencia. Añada una expiración corta, un marcador de un solo uso y un límite de tasa (rate limit); para flujos de trabajo reenviables, exija la confirmación del destinatario o el inicio de sesión antes del canje. Genere tokens con una fuente aleatoria criptográficamente segura y almacene solo un hash para que una filtración de la base de datos no se convierta inmediatamente en una credencial utilizable.
Paso 3: Controlar la filtración de la URL
OWASP señala que las URLs entran en los logs del servidor, el historial del navegador y los registros del proxy. Tras recibir el token, la landing page debería intercambiarlo por una sesión de corta duración mediante una solicitud segura y eliminarlo de la barra de direcciones. Utilice una política de referrer estricta y evite recursos de terceros que reciban el token. El correo electrónico, las capturas de pantalla y las herramientas de chat aún pueden exponer un enlace, así que no coloque en él accesos de alto privilegio y de larga duración.
Paso 4: Implementar revocación precisa y auditoría
Registre el creador, el recurso, la acción, la expiración, el último uso y la hora de revocación de cada token. Compruebe la revocación antes de cada canje o descarga; la revocación por enlace no debe depender de rotar una clave global. Audite los usos exitosos, fallidos, repetidos y revocados con sus motivos para que se puedan investigar las filtraciones y los abusos.
6. Respuesta de muestra de alta calidad
Primero clasificaría la sensibilidad y el tiempo de vida. Un manual público no necesita una capability URL. Una factura de baja sensibilidad para revisión externa puede usar una, mientras que un informe financiero sensible debería requerir inicio de sesión y permisos de organización.
>
Para el caso aceptable, genero al menos 128 bits de aleatoriedad y vinculo el token a un recurso, una acción y una ventana de 24 horas. La base de datos almacena solo el hash del token, el estado y los campos de auditoría. Un canje exitoso se marca como usado inmediatamente, y el endpoint de descarga verifica la expiración y la revocación cada vez. La respuesta establece Referrer-Policy: no-referrer; tras el canje, el token se elimina de la barra de direcciones y la página evita recursos de terceros que pudieran recibir un referrer.
>
Los usuarios pueden revocar un enlace y los administradores pueden revocar enlaces por recurso; las revocaciones y los usos repetidos se auditan. Si más adelante el producto necesita colaboración, migraría a autorización autenticada y permisos de membresía en lugar de extender la capability URL a un bearer token permanente. Esto mantiene la facilidad para compartir mientras limita la filtración a un solo recurso y a un tiempo acotado.
7. Modos de falla comunes
- Tratar un enlace largo como seguridad ignorando los logs, el historial y los reenvíos.
- Usar IDs de recursos predecibles o tokens autoincrementales.
- Colocar un bearer token de alto privilegio y larga duración en un parámetro de consulta.
- Admitir solo la rotación de claves globales y ninguna revocación por enlace.
- Dejar el token en la barra de direcciones tras el canje mientras se cargan imágenes o analíticas de terceros.
8. Preguntas de seguimiento y respuestas
Pregunta de seguimiento 1: ¿Por qué almacenar solo el hash de un token?
El token es la credencial del portador. Si se filtra el acceso de lectura a la base de datos, un token en texto plano se vuelve utilizable inmediatamente. El hashing permite al servidor comparar un valor enviado sin convertir el almacenamiento estático en un volcado de credenciales.
Pregunta de seguimiento 2: ¿El uso único hace que la actualización (refresh) falle?
Utilice el token de un solo uso para intercambiarlo por una sesión de corta duración; la actualización utiliza esa sesión en lugar de canjear el enlace original nuevamente. Si el canje tiene éxito pero se pierde la respuesta, proporcione un resultado de canje idempotente y restringido sin reabrir una autoridad de larga duración.
Pregunta de seguimiento 3: ¿Cuándo se deben abandonar por completo las capability URLs?
Utilice autorización autenticada y permisos del lado del servidor cuando el recurso sea altamente sensible, la membresía deba gestionarse continuamente, la identidad de quien realiza la llamada deba ser demostrada o la organización requiera revocación y auditoría centralizadas.