Checklist de seguridad para una app Android antes de publicar en Google Play
Una checklist clara para revisar la seguridad de una app Android antes de publicarla en Google Play.
Una checklist de seguridad para Android debe revisar datos sensibles, roles, permisos, almacenamiento local, llamadas de red, acceso al backend, autenticacion, logs, SDKs, build final y requisitos de Google Play. En un MVP no se trata de complicar el producto, sino de evitar riesgos previsibles: secretos dentro de la app, permisos excesivos, controles debiles en servidor, datos privados en logs y builds finales sin probar.
Estima tu app con un breve cuestionario
Empezar1. Datos sensibles y roles
Empieza con una lista sencilla. Que datos recoge la app?
- email, telefono, nombre y direccion;
- estado de pago, historial de pedidos o ubicacion de entrega;
- fotos, archivos o mensajes;
- datos de salud, bienestar o identidad;
- notas de soporte, acciones de administrador o ingresos de proveedores.
Despues define quien puede ver o cambiar cada dato: usuario, proveedor, soporte, administrador, repartidor, medico, profesor, vendedor o equipo financiero. Un error comun es ocultar un boton en la app, pero permitir que la API devuelva datos a quien no corresponde. Las comprobaciones del servidor son mas importantes que esconder pantallas.
2. Quita secretos del paquete de la app
Todo lo que se incluye en una app Android puede inspeccionarse. No guardes claves privadas, tokens de administrador, secretos de pago, credenciales de base de datos ni claves de firma dentro de la app.
Buenas practicas:
- pagos y acciones privilegiadas pasan por el backend;
- tokens de vida corta cuando sea posible;
- claves publicas de SDK tratadas como publicas;
- rotacion rapida de claves expuestas;
- revision de endpoints de prueba y flags de debug en la build final.
Este punto suele tener mucho impacto porque evita un fallo frecuente antes del lanzamiento.
3. Reduce permisos
Los usuarios notan los permisos, y Google Play tambien revisa los permisos sensibles. Pide solo lo necesario, en el momento en que aporta valor, y explica el motivo con lenguaje normal.
Revisa:
- ubicacion precisa o aproximada, en primer plano o en segundo plano;
- camara y acceso a medios;
- contactos y calendario;
- notificaciones;
- microfono y Bluetooth;
- permisos especiales que necesitan mas justificacion.
Si una funcion del MVP puede funcionar sin un permiso sensible, mejor evitarlo. Los permisos excesivos reducen confianza y pueden complicar la revision.
4. Protege el almacenamiento local
No guardes datos sensibles en el dispositivo si no hace falta. Si el almacenamiento local es necesario, usa almacenamiento seguro, evita tokens en texto plano y define que se borra al cerrar sesion.
Comprueba:
- tokens fuera de archivos simples;
- cache privado limitado;
- capturas y logs sin pantallas privadas;
- logout que limpia estado sensible;
- copias de seguridad sin datos que no deben copiarse.
En salud, chat privado y pagos, estas reglas deben discutirse antes del desarrollo.
5. Red y backend
El backend debe validar permisos en cada solicitud. La app Android no debe ser el unico lugar donde viven las reglas de negocio.
Revisa:
- trafico API por HTTPS;
- cada usuario accede solo a sus datos;
- roles de proveedor y administrador verificados en servidor;
- limites para acciones de riesgo;
- validacion de archivos subidos;
- estado de pago confirmado en servidor;
- errores sin detalles privados.
En marketplaces y delivery, mira con cuidado propiedad del pedido, visibilidad de direcciones y acciones de proveedores.
6. Autenticacion y recuperacion
La autenticacion incluye registro, login, login social, recuperacion de password, eliminacion de cuenta, caducidad de sesion y recuperacion por soporte.
Un MVP simple puede usar un proveedor probado. En apps con mas riesgo puede hacer falta recuperacion mas estricta, cambio de dispositivo, segundo factor o confirmacion adicional para acciones sensibles.
Si hay chat privado, notas medicas, pagos o acceso de administrador, no dejes la recuperacion de cuenta para el final.
¿Tienes una idea de app y quieres el siguiente paso?
Revisar mi idea7. SDKs, logs y analitica
Los SDKs de terceros pueden recoger datos, agregar permisos, afectar rendimiento y cambiar las declaraciones de privacidad. Mantén solo lo necesario.
Antes de publicar:
- elimina SDKs no usados;
- revisa requisitos de privacidad;
- evita datos personales, tokens o texto privado en eventos;
- revisa crash logs;
- desactiva logs verbosos en release.
La analitica debe ayudar al equipo sin convertir datos privados en ruido.
8. Play Integrity cuando tenga sentido
La documentacion Android menciona herramientas como Play Integrity API y Credential Manager. No todos los MVP necesitan lo mismo, pero apps con pagos, abuso posible, contenido de pago o marketplace deberian discutirlo.
Play Integrity aporta senales, no una muralla magica. El backend sigue necesitando permisos claros y monitorizacion.
9. Prueba la build final
Las builds de desarrollo pueden ocultar problemas. Prueba la build firmada que ira a Google Play.
Recorre:
- primera instalacion y primer login;
- recuperacion de password o login social;
- permisos;
- compra, reserva o pedido;
- logout y eliminacion de cuenta;
- red lenta u offline;
- crash reporting y analitica;
- acciones de admin si afectan al usuario Android.
Google esta incorporando mas avisos para desarrolladores, pero es mejor llegar a la revision con los problemas ya resueltos.
Coste y alcance
El esfuerzo de seguridad depende de datos y flujos. Un MVP de contenido no tiene el mismo alcance que delivery, salud, chat privado o marketplace con pagos.
En Appfyl, un MVP enfocado suele empezar alrededor de 15.000-20.000 EUR. Un producto medio suele estar entre 20.000-50.000 EUR. Apps grandes con pagos, roles, panel de administracion, datos sensibles, monitorizacion y pruebas mas profundas pueden llegar a 50.000-100.000 EUR.
La seguridad es una razon para estimar por flujos y riesgos, no solo por numero de pantallas. Puedes describirlos en el brief de estimacion de Appfyl.
Como lo aborda Appfyl
Mantenemos la primera version practica. El objetivo no es comprar todas las herramientas, sino evitar errores caros despues del lanzamiento.
Revisamos:
- datos sensibles y roles;
- permisos en backend;
- permisos de la app y almacenamiento local;
- estado de pagos, reservas o pedidos;
- analitica y logs;
- comportamiento de la build final.
Para salud, pagos o comunicacion privada, recomendamos una revision mas profunda antes del lanzamiento.
¿Quieres ver cómo Appfyl convierte el alcance en productos lanzados? Ver casos de Appfyl.
Enlaces utiles
Convierte la investigación en un plan
Appfyl convierte tu idea en un plan claro, una lista de funciones y el primer tramo de trabajo.
Hablar del plan de la appPuntos clave
- La seguridad Android empieza por datos y roles.
- Los secretos no deben estar dentro de la app.
- Pide solo permisos necesarios.
- Los controles de servidor importan mas que ocultar pantallas.
- Prueba la build firmada antes de Google Play.
Enlaces útiles
Preguntas frecuentes
No. Puede detectar parte de los problemas, pero no sustituye el diseno de seguridad, los controles de servidor, la revision de SDKs y las pruebas de release.
Confiar demasiado en la app. El servidor debe validar permisos y acciones sensibles porque el paquete puede inspeccionarse o modificarse.
No siempre. Es mas relevante cuando hay pagos, contenido de pago, marketplace, abuso o riesgo de fraude.
Si. Puede recoger datos personales, tokens, mensajes o notas privadas. Decide antes del release que no debe registrarse.
Desde el inicio, especialmente si hay cuentas, pagos, contenido privado, salud, roles o acciones de administrador.