Requisitos de seguridad de una app móvil: ¿qué debe definir una pequeña empresa antes de desarrollar?

Los requisitos de seguridad convierten el «que sea seguro» en controles verificables sobre identidad, sesiones, datos, APIs, permisos, dependencias, registros, publicaciones, incidentes y propiedad. Una pequeña empresa necesita tomar esas decisiones antes de desarrollar, porque la seguridad sale mucho más barata cuando moldea la arquitectura y los criterios de aceptación que cuando llega después del lanzamiento.

Esta guía se ocupa de los requisitos de seguridad. Complementa los materiales de Le Website sobre el documento de requisitos general, la arquitectura del backend, las responsabilidades del equipo y la preparación del lanzamiento, sin sustituir esas decisiones.

¿Qué requisitos de seguridad debe incluir una app móvil?

Deben definir quién es dueño del riesgo, la clasificación de los datos, la autenticación, la autorización, el manejo de sesiones, el cifrado, el almacenamiento seguro, los controles de la API, los permisos de privacidad, el gobierno de dependencias, las pruebas, los registros, la respuesta a incidentes, la protección de las publicaciones, la recuperación y la evidencia para aceptar. Cada requisito necesita un responsable, una amenaza concreta, un resultado medible, un método de prueba y una regla de corrección.

El estándar de verificación de seguridad móvil de OWASP ofrece una base práctica de controles para almacenamiento, criptografía, autenticación, comunicación de red, interacción con la plataforma, calidad del código, resiliencia y privacidad. Cada negocio debe ajustar esa base a sus datos, flujos, regulaciones, exposición y consecuencias de un fallo.

Escriba los controles como resultados verificables

«Usar cifrado» está incompleto. Un requisito útil nombra el dato protegido, el límite de almacenamiento o de transporte, el mecanismo aprobado de la plataforma, el dueño de las claves, qué alternativa queda prohibida, el entorno de prueba y la evidencia. Quien revise debe poder decidir si pasa o no pasa, sin interpretar una promesa vaga del equipo.

Ate cada control a un riesgo real

El alcance de la seguridad debe seguir a los usuarios, los datos, el movimiento de dinero, la autoridad operativa, las integraciones, las ubicaciones y las necesidades de disponibilidad de la app. Un catálogo público y una app de servicio en campo con registros de clientes, ubicación del personal, firmas, facturas y privilegios de administrador no merecen los mismos controles ni la misma profundidad de pruebas.

¿Cómo guían el riesgo y la clasificación de datos el alcance de la seguridad?

Clasifique datos y acciones por sensibilidad, impacto en el negocio, exposición, retención y necesidad de recuperación; después asocie amenazas creíbles a cada recorrido crítico. Refuerce los controles en pagos, identidad, salud, ubicación, registros confidenciales, acciones de administrador y acceso entre organizaciones. Registre los riesgos aceptados, los controles compensatorios, quién decidió y cuándo se revisa.

Empiece por el proceso del negocio y no por una lista genérica de vulnerabilidades. Documente qué podría cambiar, exponer, interrumpir o suplantar un atacante, un usuario deshonesto, un dispositivo perdido, un empleado comprometido, un SDK malicioso o una integración fallida. Estime consecuencia y probabilidad lo suficiente para priorizar, sin fabricar una precisión matemática falsa.

Levante un inventario de datos y de acciones

Liste cada clase de dato, su origen, su propósito, qué rol lo usa, dónde vive en el dispositivo, dónde vive en el servidor, qué terceros lo tocan, cuánto se conserva y cómo se borra o se exporta. Añada las acciones privilegiadas: devoluciones, recuperación de cuentas, cambios de precio, aprobaciones, asignación de roles y descargas masivas. Un flujo de datos oculto crea una obligación de seguridad oculta.

Haga explícita la aceptación del riesgo

Siempre queda riesgo después de aplicar controles razonables. Un responsable del negocio, con nombre, debe aceptarlo por escrito: activos afectados, escenario, impacto residual, mitigación, monitoreo, fecha de caducidad y condiciones que reabren la decisión. Un desarrollador no debería convertirse en la autoridad que acepta riesgos de la empresa solo porque se acerca una fecha de entrega.

¿Qué controles de autenticación y de sesión hay que exigir?

Exija identidad validada en el servidor, autorización según el rol, sesiones cortas y revocables, recuperación segura de credenciales, límites de intentos, manejo del cambio de dispositivo y verificación reforzada para las acciones sensibles. Prefiera la autenticación de la plataforma y los proveedores de identidad establecidos antes que un sistema de contraseñas propio. Defina el cierre de sesión, la inactividad, la renovación de tokens, el bloqueo de cuentas y qué pasa con un dispositivo comprometido antes de empezar a programar.

La autenticación demuestra quién dice ser alguien; la autorización decide qué puede hacer. Los requisitos deben probar ambas. Un usuario que cambia un identificador, repite una petición, salta de organización, restaura un token viejo o llama directamente a la API no debe obtener acceso solo porque la pantalla esconda una opción.

Proteja la recuperación con el mismo cuidado que el inicio de sesión

El restablecimiento de contraseña, el cambio de correo o de teléfono, la recuperación asistida por soporte y el reemplazo de dispositivo pueden saltarse un inicio de sesión muy robusto. Defina qué evidencia de identidad se pide, qué notificaciones se envían, qué periodos de espera aplican, cómo se evita la repetición de peticiones, hasta dónde llega la autoridad del soporte y qué queda auditado. El proceso no debe revelar si existen otras cuentas ni exponer datos del perfil.

Pida verificación adicional en las acciones de alto impacto

Una sesión puede ser cómoda para la actividad diaria y aun así exigir reautenticación reciente o verificación extra para pagos, exportaciones, cambios de titularidad, concesión de permisos de administrador o acciones destructivas. Especifique qué acciones disparan esa verificación, cuánto tiempo sigue siendo válida y qué ocurre cuando no se puede completar.

¿Cómo se protegen los datos en el dispositivo y en tránsito?

Guarde solo lo necesario, use el almacenamiento protegido del sistema operativo para los secretos, cifre el tráfico sensible con las librerías vigentes de la plataforma, valide las decisiones de confianza e impida que valores confidenciales acaben en registros, respaldos, notificaciones, capturas de pantalla, portapapeles o archivos compartidos. Defina la retención sin conexión, el vaciado de caché, la transferencia de dispositivo, el cierre de sesión, el borrado de cuenta y qué hacer ante un equipo perdido.

Apple documenta la seguridad del hardware, el cifrado, la protección de datos y el llavero en Apple Platform Security, y Android ofrece mecanismos equivalentes. Los requisitos deben pedir mecanismos soportados y evidencia, no criptografía casera ni el supuesto de que el sistema operativo protege automáticamente todos los archivos de una aplicación.

Separe los secretos del resto de los datos

Los tokens de acceso, las claves de cifrado, los códigos de recuperación, el material de firma y las credenciales privadas necesitan almacenamiento controlado y reglas de ciclo de vida. No meta secretos del servidor dentro del paquete de la app: cualquiera puede inspeccionar el software instalado. Defina creación, acceso, rotación, revocación, respaldo y destrucción para cada tipo de secreto.

Revise todas las salidas de datos

Inspeccione registros, envíos de analítica, reportes de fallos, notificaciones, archivos exportados, menús de compartir, capturas, portapapeles, respaldos, contenido web cacheado y herramientas de soporte. Una base de datos puede estar cifrada mientras un SDK de telemetría de terceros manda ese mismo dato sensible a otro sitio en texto claro.

¿Qué controles deben imponer la API y el backend?

El backend debe autenticar cada petición por su cuenta, autorizar cada objeto y cada acción, validar las entradas, aislar organizaciones, proteger secretos, limitar el abuso, prevenir la repetición de peticiones cuando corresponda, registrar eventos auditables y fallar de forma segura. Nunca confíe en un botón oculto, una bandera de rol local, un identificador de dispositivo o una validación del lado del cliente como frontera final de seguridad.

La guía de requisitos del backend de una app móvil cubre a fondo modelos de datos, APIs, integraciones, fiabilidad, observabilidad, despliegue y propiedad. Los requisitos de seguridad deben colgar controles concretos y pruebas negativas de esas decisiones de arquitectura, sobre todo donde el backend expone registros de clientes o flujos privilegiados.

Pruebe la autorización a nivel de objeto y de organización

Para cada endpoint, intente el acceso sin identidad, con el usuario equivocado, con un rol inferior, desde otra sucursal, desde otra organización, cambiando identificadores de objeto, con sesiones vencidas y con accesos revocados. Las pruebas positivas demuestran que el trabajo legítimo funciona; las negativas demuestran que el servidor rechaza caminos que la interfaz nunca pensó ofrecer.

Diseñe un comportamiento seguro ante el fallo

Las respuestas de error deben permitir una recuperación legítima sin revelar credenciales, rutas internas, detalles de la base de datos, la existencia de otras organizaciones ni registros sensibles. Defina códigos de estado consistentes, identificadores de correlación, reglas de reintento, cortacircuitos y mensajes al usuario. Un control de seguridad que provoca reintentos infinitos o estados ambiguos crea otro riesgo operativo.

¿Cómo se especifican permisos, privacidad y minimización de datos?

Pida solo los permisos y los datos personales que exige una función concreta, explique el motivo en el momento adecuado, funcione con dignidad cuando el usuario diga que no, y defina retención y borrado. Inventaríe cada SDK de analítica, reporte de fallos, mapas, pagos y soporte. Los requisitos deben cubrir consentimiento, borrado de cuenta, exportaciones, ubicación, contactos, fotos, micrófono y notificaciones cuando apliquen.

La privacidad no se resuelve con una página de política. Son los requisitos del producto los que determinan si la app puede funcionar recopilando menos, si el personal ve registros que no necesita, si el usuario entiende un permiso y si el borrado llega de verdad a las bases operativas, los archivos, los proveedores, los registros y los respaldos.

Diseñe para el permiso denegado o revocado

El usuario puede rechazar una solicitud, revocarla después, dar solo ubicación aproximada, compartir unas pocas fotos o desactivar las notificaciones. Defina qué función deja de estar disponible, cómo explica la app esa limitación, dónde se cambian los ajustes y qué flujo alternativo queda. Insistir con avisos repetidos no es una estrategia de recuperación.

Revise el comportamiento de cada SDK de terceros

Documente para cada SDK su propósito, su dueño, qué datos recopila, a dónde los envía, qué permisos pide, cuánto los conserva, bajo qué contrato, cómo se actualiza y cómo se retiraría. Una librería aparentemente inofensiva puede introducir rastreadores, código vulnerable, permisos amplios o llamadas de red inesperadas. Apruebe los SDK con evidencia actual y vuelva a revisarlos cuando cambien de versión o de uso.

¿Qué requisitos de desarrollo seguro y cadena de suministro importan?

Exija estándares de código revisados, análisis de secretos, inventario de dependencias, versiones soportadas, triaje de vulnerabilidades, repositorios protegidos, revisión entre pares, pruebas automatizadas, entornos aislados, acceso mínimo a las compilaciones, registros de publicación reproducibles y claves de firma protegidas. Defina plazos de actualización según severidad y exposición, y un proceso de excepción que registre riesgo, responsable, caducidad y controles compensatorios.

El marco de desarrollo de software seguro del NIST organiza estas prácticas en preparar la organización, proteger el software, producirlo de forma segura y responder a vulnerabilidades. Sirve muy bien para exigencias de proceso y de proveedores, mientras que OWASP MASVS aporta el detalle de verificación específico de móvil.

Mantenga un inventario de dependencias y SDK

Registre componentes directos e indirectos, versiones, licencias, origen, responsable, propósito, estado de mantenimiento, riesgos conocidos y alternativas. Escanear no basta si nadie se hace cargo de corregir. Los requisitos deben definir cómo se evalúa un aviso nuevo, cómo se identifican las versiones afectadas y cuándo hay que publicar una actualización de emergencia.

Proteja los sistemas de compilación y de firma

Limite quién puede modificar los flujos de publicación, aprobar compilaciones de producción, acceder al material de firma o publicar versiones en las tiendas. Separe credenciales de desarrollo y de producción, registre las aprobaciones y haga detectable cualquier cambio inesperado. Un código seguro puede terminar publicando un artefacto comprometido si la ruta de compilación es débil.

¿Cómo se planifican las pruebas de seguridad?

Planifíquelas desde los requisitos hasta la publicación: revisión de arquitectura, revisión de código, análisis automatizado, escaneo de dependencias, pruebas de API, inspección en el dispositivo, casos de abuso y pruebas de penetración según el riesgo. Defina alcance, entornos, cuentas, datos, herramientas, independencia, criterios de severidad, plazos de corrección, evidencia de reprueba, limitaciones aceptadas y quién autoriza publicar.

Las pruebas deben verificar el binario real, el backend, la configuración, las integraciones y la versión candidata; no solo el código fuente o un entorno de demostración. Las buenas prácticas de seguridad de Android resumen la guía de plataforma sobre comunicación, almacenamiento, permisos, autenticación, dependencias y uso de WebView.

Escriba casos de abuso junto a las historias de usuario

Para cada recorrido crítico, pregúntese cómo alguien podría suplantar a un usuario, alterar identificadores, saltarse pasos, repetir peticiones, automatizar el abuso, superar límites, ver datos de otra organización, manipular información guardada sin conexión o explotar la recuperación. Convierta las rutas creíbles en controles preventivos, detección, pruebas y una respuesta segura.

Exija corrección y reprueba

Un informe por sí solo no reduce el riesgo. Defina criterios de severidad, contexto de negocio, responsable de la corrección, fecha objetivo, mitigación temporal, quién puede aceptar el riesgo y cómo se vuelve a probar. Cerrar un hallazgo exige evidencia nueva contra la versión corregida; una captura de un ticket marcado como «listo» no es verificación independiente.

¿Qué requisitos de registro, monitoreo y respuesta a incidentes hacen falta?

Registre los eventos relevantes para la seguridad sin guardar secretos ni datos personales innecesarios; proteja su integridad y su acceso; defina la retención; y cree alertas accionables ante autenticaciones sospechosas, cambios de privilegios, intentos de cruzar organizaciones, abuso, exportaciones y publicaciones. Asigne antes del lanzamiento las responsabilidades de detección, triaje, contención, comunicación, recuperación, preservación de evidencia y revisión posterior.

Un registro útil conecta el evento con la hora, el entorno, la versión, la cuenta o el actor seudónimo, la acción, el objetivo, el resultado y un identificador de correlación. Debe ayudar a reconstruir lo ocurrido sin convertirse en una segunda base de datos sensible. Los umbrales de alerta deben probarse para que la actividad normal no sepulte las señales importantes.

Haga un simulacro corto de incidente

Recorra el caso de una clave de firma perdida, un token expuesto, una publicación maliciosa, un administrador comprometido, una exportación de datos o un SDK vulnerable. Confirme rutas de contacto, autoridad para decidir, acceso a las tiendas, disponibilidad de registros, comunicación al cliente, reversión, rotación de credenciales y recuperación. El simulacro debe producir manuales corregidos, no solo un acta de reunión.

Ponga límites a la telemetría de seguridad

Indique qué eventos son obligatorios, qué campos están prohibidos, cuánto se conservan, quién puede verlos, qué restricciones geográficas o de proveedor aplican, a dónde van las alertas y cómo se borran. Pruebe la telemetría en flujos reales. Si el proveedor de monitoreo falla, la app no debe exponer datos sensibles, ni bloquear clientes sin necesidad, ni ocultar que se perdió la visibilidad.

¿Cómo se aseguran la publicación y las cuentas de las tiendas?

Proteja las cuentas de desarrollador con autenticación fuerte, reduzca al mínimo los privilegios de publicación, resguarde las claves de firma, separe entornos, revise la configuración de producción y conserve un registro auditable de cada versión. Defina la reversión de emergencia, el despliegue por fases, la revisión de seguridad, las declaraciones en las tiendas, la evidencia de dependencias y el monitoreo posterior. Ningún colaborador externo debe conservar el control exclusivo del código, las credenciales, la firma o la publicación.

La lista de verificación para lanzar una app móvil cubre los materiales de tienda, las declaraciones de privacidad, la analítica, el soporte, la propiedad y la operación del lanzamiento. La aceptación de seguridad debe ser una puerta con nombre dentro de ese proceso, conservando hallazgos abiertos, decisiones de riesgo, identificadores de la versión, aprobadores y evidencia de reversión.

Permisos mínimos en las cuentas de tienda

Las cuentas de Apple y Google deben estar a nombre del negocio y dar a cada persona solo el acceso que necesita. Revise la membresía con regularidad, retire a quien se va, proteja los métodos de recuperación y evite credenciales compartidas. Registre quién aprobó y quién envió cada versión, para que una emergencia no dependa de reconstruir un proceso informal.

Verifique el artefacto que llega a producción

Confirme que la versión enviada a la tienda coincide con la que se revisó, usa configuración segura de producción, no incluye herramientas de depuración ni endpoints de prueba, no lleva secretos incrustados y solo se conecta a servicios aprobados. Conserve versión, identificador de compilación, commit de origen, registro de dependencias, evidencia de firma, resultado de pruebas y aprobación para futuras investigaciones.

¿Quién es dueño de la evidencia y del traspaso después del lanzamiento?

Un responsable del negocio acepta el riesgo residual; producto e ingeniería mantienen los requisitos; quien revisa la seguridad verifica los controles; y operación se hace cargo del monitoreo y la respuesta. El negocio debe conservar repositorios, cuentas, acceso a la firma, registros de arquitectura, mapas de datos, pruebas, hallazgos, excepciones, manuales, contactos de proveedores, respaldos y una cadencia de revisión.

La guía de roles del equipo de desarrollo móvil explica cómo combinar responsabilidades sin volverlas invisibles. En un equipo pequeño una persona puede llevar varios papeles, pero las decisiones de seguridad, su verificación y su aceptación siguen necesitando un responsable con nombre y evidencia que sobreviva al cambio de proveedor o de empleado.

Convierta el traspaso en un entregable del contrato

Especifique exactamente qué recibe el negocio: cuentas, repositorios, flujos de compilación, esquema de firma, entornos, documentación, inventarios, artefactos de prueba, hallazgos abiertos, licencias, contactos de soporte y sesiones de transferencia de conocimiento. La aceptación debe exigir acceso confirmado y un ejercicio exitoso de publicación o recuperación, no una carpeta entregada el último día.

Programe revisiones según el riesgo

Revise tras funciones importantes, cambios en los datos, incorporación de SDK, cambios de autenticación, incidentes, actualizaciones de plataforma, rotación del equipo u obligaciones nuevas. Fije además un punto de control periódico. Los requisitos de seguridad envejecen conforme cambian el producto, las amenazas, los proveedores, los sistemas operativos y las consecuencias para el negocio; un informe antiguo aprobado no es una garantía permanente.

Preguntas frecuentes sobre los requisitos de seguridad de una app móvil

Las dudas más comunes son si bastan las protecciones de la plataforma, cuándo se justifica una prueba de penetración, quién es responsable de la seguridad, si las herramientas sin código eximen de responsabilidad y cuánta documentación es razonable. La respuesta depende del riesgo, pero toda app necesita controles explícitos, evidencia, responsables con nombre y un plan para las vulnerabilidades que aparezcan después de publicar.

¿Basta con la revisión de App Store y Google Play?

No. La revisión de las tiendas y las protecciones de la plataforma son filtros valiosos, pero no demuestran que un negocio concreto aplique correctamente la autorización, el aislamiento entre organizaciones, el tratamiento de datos, la seguridad de la API, la recuperación, el monitoreo ni la propiedad operativa. El equipo sigue necesitando verificación basada en riesgo de toda la app y su backend.

¿Toda app de una pequeña empresa necesita una prueba de penetración?

No todas las versiones requieren la misma profundidad de prueba independiente. Se justifica más cuando la app maneja registros sensibles, pagos, operaciones privilegiadas, varias organizaciones, flujos regulados, APIs públicas o cuando una interrupción tendría consecuencias serias. Alrededor de esa decisión siguen siendo necesarias la revisión de arquitectura, el análisis automatizado, la revisión de código y las pruebas negativas.

¿Una plataforma sin código resuelve la seguridad automáticamente?

Una plataforma puede aportar controles útiles de identidad, almacenamiento, despliegue y parcheo, pero el negocio sigue configurando roles, acceso a datos, integraciones, permisos, flujos, retención y respuesta a incidentes. Hay que revisar la evidencia del proveedor y probar —no suponer— la autorización y el comportamiento de privacidad propios de la aplicación.

¿Quién es responsable de la seguridad después del lanzamiento?

La responsabilidad es compartida, pero debe ser explícita. El negocio es dueño del riesgo y de las cuentas; el proveedor de desarrollo mantiene los controles acordados; los proveedores de nube y plataforma aseguran los servicios definidos; y operación monitorea y responde. Los contratos deben fijar límites, tiempos de respuesta, actualizaciones, evidencia, accesos y qué ocurre al terminar la relación.

¿Cada cuánto se revisan los requisitos de seguridad?

Con una cadencia periódica definida y, además, siempre que cambien los datos sensibles, los flujos críticos, la autenticación, las integraciones, los SDK, la infraestructura, la regulación, la propiedad o la exposición a amenazas. Los hallazgos de alto riesgo y los incidentes activos exigen decisiones inmediatas. Cada revisión debe actualizar evidencia, responsables, excepciones, fechas de corrección y el siguiente punto de control.

¿Cuál es el siguiente paso?

Empiece con un taller corto de riesgo, un inventario de datos y acciones, un mapa de arquitectura y responsables con nombre. Convierta los escenarios de mayor impacto en requisitos y pruebas de aceptación antes de estimar el desarrollo. Si Le Website va a planificar o revisar el proyecto, escríbanos para conectar el alcance de seguridad con las decisiones de producto, backend, pruebas, lanzamiento y propiedad.

Traiga el documento de requisitos de la app, los flujos actuales, los roles de usuario, los tipos de dato, las integraciones, la lista de proveedores y las restricciones conocidas. Una revisión enfocada puede identificar los controles, la evidencia, la propiedad y las puertas de publicación que faltan, antes de que esos huecos se conviertan en incidentes caros en producción.

Revisado el 23 de agosto de 2026. Este artículo ofrece orientación general de planificación; no constituye asesoría legal, regulatoria ni de respuesta a incidentes para una organización concreta.