Revisar la seguridad de un web part de SharePoint de terceros
Última actualización:
Un paquete de SharePoint Framework ejecuta JavaScript en las páginas de tu intranet, en los navegadores de tus usuarios y con sus sesiones. Eso merece una revisión — pero la revisión es más corta y más concreta de lo que casi todo el mundo supone, porque casi todo lo que necesitas está dentro del propio paquete y puedes leerlo antes de desplegar nada.
La versión corta: descomprime el .sppkg, lee los manifiestos, juzga la solicitud de permisos, averigua a dónde van los datos y confirma cómo se desinstala. Cinco pasos, una tarde como mucho. El resto de esta página es cada uno en detalle, más las preguntas que merece la pena mandarle al proveedor.
Un encuadre que ayuda: no estás evaluando si el proveedor es de fiar en general. Estás evaluando cuánto daño es posible si resulta que no lo es — que es una pregunta sobre permisos y flujo de datos, y esa sí tiene respuesta.
1. Abre el paquete
Un .sppkg es un archivo zip. Renómbralo y extráelo. No necesitas permiso del proveedor ni haber comprado nada — y si no te dan el paquete antes de comprometerte, eso ya es un hallazgo.
| Qué mirar | Qué estás comprobando |
|---|---|
| El manifiesto de la solución | Las solicitudes de permiso de API, la versión y si la solución es de alcance de tenant. |
| <code>requiresCustomScript</code> | Si es true, el componente puede incrustar script escrito por los autores de las páginas. Trátalo como una categoría de riesgo mucho más alta. |
| <code>includeClientSideAssets</code> | Si es true, el JavaScript se sirve desde tu propio tenant. Si es false, se carga del CDN del proveedor y puede cambiar sin que tú redespliegues nada. |
| Los assets de cliente | El bundle real. Estará minificado, pero aun así puedes buscar URLs dentro — y eso te dice todos los hosts con los que el componente puede hablar. |
| Metadatos del fabricante | Nombre, URL de privacidad, términos de uso. Los campos en blanco son una señal de madurez. |
Esa cuarta fila son los diez minutos más rentables de toda la revisión: busca http dentro del bundle. Todos los endpoints con los que el componente puede hablar están ahí.
2. Juzga la solicitud de permisos
El manifiesto declara lo que el paquete va a pedir. Las aprobaciones ocurren después, en el centro de administración, pero puedes leer la solicitud ahora y decidir antes de desplegar nada.
- ¿Cuántos scopes? Un solo scope estrecho es buena señal. Una lista de ellos para un componente que enseña una tabla, no.
- ¿De quién es la API? Una solicitud contra
Microsoft Graphalcanza tus datos de Microsoft 365. Una contra la API del propio proveedor, no. - ¿Lectura o escritura? Que justifiquen cualquier
ReadWrite. - ¿Cómo de amplio?
.Allsignifica todo el tenant, no lo que ve el usuario actual.
También conviene saberlo, porque elimina un miedo habitual: un paquete no puede adquirir permisos nuevos en silencio al actualizarse. Una solicitud nueva aparece como pendiente en tu centro de administración y no tiene ningún efecto hasta que un administrador la apruebe.
3. Averigua a dónde van los datos de verdad
Aquí es donde los proveedores son más vagos y donde está el riesgo real. Hay dos arquitecturas y no son comparables:
| Lee en el navegador | Lee a través del backend del proveedor | |
|---|---|---|
| Quién pide las filas | El navegador del usuario, con su propia sesión | Los servidores del proveedor, con una credencial guardada |
| ¿Salen tus filas del tenant? | No | Sí |
| Permisos que se aplican | Los de SharePoint, por usuario, sin cambios | Los que permita la concesión guardada |
| Si comprometen al proveedor | No tienen copia de tus datos ni acceso permanente | Pueden tener las dos cosas |
Pregúntalo directamente: «¿Las filas de nuestras listas pasan en algún momento por vuestros servidores?» Y contrasta la respuesta con lo que encontraste en el paso 1: si el bundle solo llama a SharePoint para los datos y a la API del proveedor para la configuración, la arquitectura coincide con lo que dicen.
4. Confirma cómo se sale
No apruebes nada cuya salida no hayas entendido. Tres preguntas:
- ¿Qué pasa con los datos si lo quitamos? Si la herramienta escribía en listas de SharePoint, los datos simplemente se quedan ahí. Si viven en la base de datos del proveedor, necesitas una vía de exportación por escrito.
- ¿Cómo revocamos el acceso? Quitar el permiso de API y borrar el paquete del catálogo debería bastar. Si hay además una aplicación de Entra ID que limpiar, entérate ahora.
- ¿Podemos desactivar un componente sin desinstalarlo todo? En cualquier cosa desplegada a todo el tenant, esto importa la primera vez que uno se porta mal.
5. Las preguntas que hay que mandarle al proveedor
- ¿Qué permisos de API pide el paquete y qué funcionalidad necesita cada uno?
- ¿El contenido de nuestras listas de SharePoint llega en algún momento a vuestra infraestructura?
- ¿Guardáis alguna credencial o token de nuestro tenant?
- ¿Quiénes son vuestros subencargados, qué ve cada uno y en qué región?
- ¿Firmáis un DPA?
- ¿Cuál es el SHA-256 publicado del paquete, para que podamos verificar lo que hemos descargado?
- ¿Qué pasa con nuestros datos y nuestros componentes si cancelamos?
Lo rápido y lo concreto que vuelvan te dice tanto como las respuestas. Un proveedor que ha pensado en esto las tiene publicadas; uno que no, te manda un dossier comercial. Sharelio publica las siete en sharelio.com/es/seguridad, y el paquete y su hash se pueden descargar sin cuenta.
Preguntas frecuentes
¿Hace falta leerse el JavaScript minificado?
Leerlo línea a línea casi nunca compensa y casi nunca es concluyente. Buscar dentro sí: extrae el bundle y busca URLs para enumerar todos los hosts con los que el componente puede hablar, y términos como eval o innerHTML si quieres una idea rápida de cómo pinta. Los manifiestos y la pregunta del flujo de datos te dicen mucho más por minuto invertido.
¿Un web part de AppSource es seguro por definición?
Más seguro, no seguro. La certificación de Microsoft comprueba que la solución se comporta, que no deja al usuario final inyectar script arbitrario, que declara metadatos de fabricante válidos y que funciona como se describe. No audita el backend del proveedor, ni sus subencargados, ni su tratamiento de datos. Estar en AppSource es una señal útil que sube el suelo; no sustituye a los pasos 2 a 4 de arriba.
¿Cuál es la mayor señal de alarma?
Una solicitud de scopes amplios de Microsoft Graph que nadie sabe atar a una funcionalidad concreta, sobre todo si son permisos de aplicación (app-only), que no están limitados por quién esté mirando la página. Muy de cerca: un proveedor que no sabe decir claramente si tus datos pasan por sus servidores.
¿Cuánto debería durar esta revisión?
Para un paquete bien documentado, una tarde: una hora con el paquete, una hora con la documentación del proveedor y un intercambio corto de preguntas. Si está tardando semanas, el retraso suele ser organizativo y no técnico — y conviene decirlo en voz alta, porque es lo que de verdad está impidiendo al negocio tener su herramienta.