[Blog]()Portales # Permisos de un portal: cada cliente solo ve lo que corresponde Una sesión válida no da permiso sobre todos los archivos. Comprueba la misma frontera en buscador, descarga, exportación y enlaces compartidos. **[Jonathan Perez]()**Cofundador · Diseño, producto y ventas 8 de octubre de 2026 · 7 min de lectura **Respuesta breve** Para definir permisos de un portal de clientes, relaciona cada persona con empresa, sucursal, documentos y acciones autorizadas. Prueba accesos permitidos y rechazados con cuentas ficticias, incluidos enlaces directos, archivos y sesiones abiertas tras revocar. Conserva evidencia de la decisión y no asumas protección porque una sección esté oculta. ## Prueba diez límites de acceso del cliente Usa clientes, sucursales y documentos ficticios para accesos permitidos, rechazados y revocados; resultados observados vacíos. [Descargar hoja CSV]() En esta guía - [Entrar al portal no autoriza a consultar cualquier registro]() - [Ejemplo: un enlace de Norte llega a Verde]() - [Prueba la revocación desde una sesión abierta]() - [Pide casos permitidos y rechazados]() ## Entrar al portal no autoriza a consultar cualquier registro Un portal de clientes debe comprobar quién consulta, a qué empresa y sucursal pertenece, qué documento solicita y qué acción tiene permitida. Ocultar una sección del menú no demuestra que el archivo esté protegido. La misma regla debe mantenerse al buscar, abrir un enlace directo, descargar, exportar o cambiar datos. [OWASP recomienda]() conceder solo permisos necesarios, denegar por defecto y verificar autorización en cada consulta. [Microsoft advierte]() para Power Pages que ocultar páginas no las protege y que se deben probar descargas directas con personas sin acceso o sin sesión. Son recomendaciones y condiciones de esas fuentes; la demostración debe comprobar tus propios límites. | Persona |Alcance |Acción permitida | | --- | --- | --- | | Comprador de Norte |Azul, sucursal Norte |Consultar pedidos autorizados de Norte | | Administrativo de Norte |Azul, sucursal Norte |Consultar documentos financieros habilitados de Norte | | Contacto de Centro |Azul, sucursal Centro |Solo registros habilitados de Centro | | Contacto de Verde |Cliente Verde |Solo registros de Verde | | Sin sesión o revocado |Ningún registro privado |Rechazo sin datos privados | ## Ejemplo: un enlace de Norte llega a Verde **Escenario sintético en una prueba autorizada** Azul y Verde son clientes ficticios. DOC-41 pertenece a Azul-Norte y contiene un documento financiero de prueba. AN puede consultar esos documentos de Norte; AC solo Centro; V solo Verde. No se usan cuentas ni documentos reales, ni se prueba un portal de terceros sin autorización. AN abre DOC-41 correctamente. Copia el enlace y lo intenta abrir como V: se espera rechazo sin archivo, importe ni otros detalles privados. AC también debe recibir rechazo aunque pertenezca a Azul, porque su alcance de prueba es Centro. Iniciar sesión identifica a la persona; no amplía automáticamente sus sucursales. V busca el número de DOC-41, exporta sus documentos permitidos y consulta una vista de detalle. Ningún camino debe revelar Azul. El equipo revisa contenido, totales y archivos, no solo un botón oculto. Si hay enlaces compartidos especiales, define quién los emite, qué permiten, cuándo caducan y cómo se retiran; cada excepción necesita su propia prueba. El comprador de Norte ve pedidos, pero no DOC-41 según la matriz. Cambiar al perfil administrativo autorizado requiere aprobación y volver a evaluar el alcance. No debe ampliarse porque alguien le envió una URL. Repetir la misma asignación debe conservar el mismo permiso, sin activar todas las sucursales. ## Prueba la revocación desde una sesión abierta En otra variante, se retira acceso a AN mientras tiene una sesión abierta. Su siguiente consulta y nueva descarga deben rechazarse según la regla definida; otro inicio de sesión tampoco debe recuperar el permiso. Conserva quién aprobó la revocación y cuándo. Comprueba el resultado después del cambio, además del texto de administración. Una copia ya descargada no debe tratarse como si desapareciera al retirar acceso futuro. Define manejo y conservación con tus responsables. Conservar historial del permiso no significa mantener habilitado al usuario. Si se revoca por error, restaurar acceso requiere aprobación y una nueva prueba de alcance. | Camino |Comprobación |Resultado de V ante DOC-41 | | --- | --- | --- | | Menú y buscador |Contenido y totales |Sin registro ni detalles privados | | Enlace directo |Documento o vista |Rechazo sin contenido | | Descarga y exportación |Archivos y filas |Solo Verde autorizado | | Cambio de datos |Registro y acción |No modifica Azul | | Después de revocar |Nueva consulta y descarga |Permiso retirado no reaparece | ## Pide casos permitidos y rechazados - Crea dos clientes ficticios y dos sucursales de uno. Confirma un acceso permitido antes de comparar los rechazados. - Prueba el mismo documento desde otra empresa, sucursal, perfil sin permiso y persona sin sesión. - Usa búsqueda, enlace directo, descarga y exportación. Revisa datos privados incluso en totales o mensajes de error. - Retira un permiso con la sesión abierta. Prueba una ampliación autorizada y su repetición. - Guarda usuario de prueba, acción, resultado esperado, observado y versión evaluada, sin contraseñas ni documentos de producción. Estas diez pruebas no certifican seguridad completa. Revisan límites concretos antes de invitar clientes y después de cambios relevantes. Si aparece información ajena, registra el caso y corrige la frontera antes de ampliar acceso; ocultarla después de entregar el archivo es insuficiente. El equipo técnico debe ampliar pruebas según el alcance real. Prepara perfiles, clientes, sucursales, documentos y acciones. Decide quién autoriza accesos y bajas, qué excepciones de compartición existen y qué datos son privados. Para alcance general revisa [portal de clientes](); para controles comerciales, [precios por cliente B2B](). Una consulta sobre [portal a la medida]() puede revisar esa matriz antes de definir pantallas. ## Revisemos quién puede ver cada documento Una consulta gratuita puede revisar tu matriz de clientes, sucursales y acciones antes de definir el portal. - Perfiles de cliente, sucursales y acciones permitidas, sin credenciales. - Tres tipos de documento ficticio y quién debe poder consultarlos. - Quién autoriza acceso, revocación y excepciones de compartición. [Agendar diagnóstico gratuito]()[Consultar por WhatsApp]() Relacionado - [Ventas y portal de clientes]() - [ERP y CRM a la medida]() ## Preguntas frecuentes ### ¿Ocultar un menú protege los documentos? No lo demuestra. Prueba búsqueda, enlace directo, descarga y exportación con una persona sin permiso. El sistema debe negar el contenido, no solo esconder el botón. ### ¿Todos los contactos ven todas las sucursales? Solo si tu regla lo autoriza. Define alcance por contacto, empresa, sucursal y acción; comprueba que pertenecer a una empresa no amplíe permisos sin aprobación. ### ¿Qué pruebo al revocar acceso? Nueva consulta, descarga y entrada desde una sesión que ya estaba abierta. Conserva aprobación e historial y verifica que los permisos retirados no reaparezcan. ### ¿Diez casos garantizan seguridad? No. Son una base para los límites descritos. Amplía y repite pruebas según funciones, documentos, cambios y riesgos del portal. ## Fuentes 1. [Autorización y permisos mínimos]()OWASP 2. [Seguridad y prueba de descargas en Power Pages]()Microsoft Learn Última actualización: 8 de octubre de 2026 ## Sigue leyendo [Ventas8 oct 2026 ### Precios por cliente en un portal B2B: vigencia, descuentos y pruebas]()[Auditoría de cambios8 oct 2026 ### Bitácora de cambios: quién cambió qué y cómo investigar una diferencia]()[Guías2 oct 2026 ### Qué es un portal de clientes y cuándo le conviene a tu empresa]() --- Canonical: https://nightlysoftware.com/blog/permisos-portal-clientes Updated: 2026-10-08 Description: Prueba límites por cliente, sucursal, documento y acción. Revisa enlaces directos, descargas y revocación con diez casos sintéticos descargables.