Los permisos "peligrosos" en Android son los que dan acceso a datos o acciones sensibles, como la ubicación, la cámara, el micrófono o los contactos, y por eso el sistema los solicita en tiempo de ejecución y el usuario puede concederlos o denegarlos. No se llaman peligrosos porque tu app sea maliciosa, sino porque el dato que tocan es delicado. Declarar solo los que de verdad necesitas es una de las decisiones de seguridad más importantes, y también una de las que más influyen en la revisión de la tienda.
Respuesta rápida
Un permiso "peligroso" en Android es un permiso de tiempo de ejecución que, según la documentación de Android, da a tu app "acceso adicional a datos restringidos o le permite realizar acciones restringidas que afectan de forma más sustancial al sistema y a otras apps". Desde Android 6.0 (API 23), deben solicitarse en tiempo de ejecución y el usuario decide. Las categorías incluyen ubicación, cámara, micrófono, contactos, SMS y teléfono, almacenamiento, sensores corporales y calendario. La regla de oro es declarar y pedir solo los mínimos necesarios.
¿Qué son los permisos "peligrosos" en Android?
Los permisos peligrosos son una de las categorías de protección de Android, junto con los normales, los de firma y los especiales. Los normales se conceden automáticamente al instalar y tienen bajo riesgo; los de firma requieren la misma clave que la app o el sistema que los define; los peligrosos, en cambio, protegen datos sensibles y requieren el consentimiento explícito del usuario en tiempo de ejecución.
La documentación de Android es clara: no debes asumir que un permiso peligroso ya fue concedido, sino comprobarlo y, si hace falta, solicitarlo antes de cada acceso. Este modelo, vigente desde Android 6.0, cambió la lógica: ya no basta con declarar el permiso en el manifiesto, hay que pedirlo cuando el usuario realiza la acción que lo necesita, y manejar el caso en que lo deniegue. Por eso, un permiso peligroso mal gestionado no solo es un riesgo de privacidad, también puede romper la experiencia si la app da por hecho un acceso que el usuario nunca concedió.
La lista de permisos peligrosos por categoría
Los permisos peligrosos se agrupan por el tipo de dato o hardware que protegen. La siguiente tabla resume las categorías principales con ejemplos concretos.
| Categoría | Permisos de ejemplo | Dato o acción que protege |
|---|---|---|
| Ubicación | ACCESS_FINE_LOCATION, ACCESS_COARSE_LOCATION | GPS y ubicación por red |
| Cámara | CAMERA | Acceso a la cámara |
| Micrófono | RECORD_AUDIO | Grabación de audio |
| Contactos | READ_CONTACTS, WRITE_CONTACTS | Agenda del usuario |
| SMS y teléfono | READ_SMS, SEND_SMS, READ_PHONE_STATE | Mensajes y llamadas |
| Almacenamiento | READ_EXTERNAL_STORAGE, WRITE_EXTERNAL_STORAGE | Archivos y contenido multimedia |
| Sensores corporales | BODY_SENSORS | Ritmo cardíaco y datos de actividad |
| Calendario | READ_CALENDAR, WRITE_CALENDAR | Eventos del calendario |
Los permisos del mismo grupo suelen presentarse juntos al usuario en un solo diálogo. Conviene tratar cada categoría como una decisión aparte: pedir la ubicación no obliga a pedir los contactos, y cada permiso que añades aumenta tanto el riesgo de privacidad como las preguntas que hará la revisión de la tienda. La lista completa de permisos figura en la referencia oficial de Android, pero la mayoría de las apps solo debería tocar unas pocas de estas categorías.
¿Por qué importan para la seguridad y la revisión de la tienda?
Los permisos peligrosos importan porque amplían la superficie de datos sensibles a los que tu app puede acceder, y con ella el impacto de cualquier fallo o filtración. Una app que pide más permisos de los que usa amplía el riesgo sin beneficio: si un atacante compromete la app o una de sus librerías, esos permisos ya concedidos se convierten en accesos disponibles para el ataque.
También influyen en la publicación. Google Play exige justificar el uso de permisos sensibles, y un permiso declarado sin una función clara que lo respalde puede provocar preguntas o un rechazo. Pedir el mínimo no es solo buena higiene de seguridad, es la forma más simple de evitar fricción en la revisión y de mantener la confianza del usuario cuando ve el diálogo de permisos y entiende por qué se lo pides. Un ejemplo habitual es el permiso de ubicación en segundo plano, que Google trata con especial cuidado: solicitarlo sin una función que lo justifique de forma clara es una de las causas más frecuentes de preguntas y demoras en la revisión.
¿Qué revisar primero en tu app?
Lo primero es abrir el AndroidManifest.xml y listar todos los permisos declarados. Muchas apps arrastran permisos que ya no usan, añadidos por una función que se eliminó o por una librería de terceros. Cada permiso peligroso en el manifiesto debería corresponder a una función real y actual de la app, y si no puedes nombrar la función que lo usa, probablemente sobra.
Después, revisa cómo se solicitan. Los permisos peligrosos deben pedirse en tiempo de ejecución, idealmente justo antes de la acción que los necesita, no todos de golpe al abrir la app. Comprueba también que la app siga funcionando de forma razonable si el usuario deniega un permiso, porque una denegación no debería romper toda la experiencia. Un buen manejo de la denegación es, además, una señal de calidad que la revisión de la tienda valora.
Cómo minimizar permisos, paso a paso
La regla es simple: declara y solicita solo el mínimo. La siguiente tabla ordena los pasos en el orden que conviene seguir.
| Paso | Acción |
|---|---|
| 1. Auditar el manifiesto | Lista todos los permisos declarados en AndroidManifest.xml |
| 2. Eliminar los no usados | Quita los permisos que ninguna función necesita |
| 3. Solicitar en tiempo de ejecución | Pide los peligrosos justo antes de usarlos, no al inicio |
| 4. Manejar la denegación | Asegura que la app funcione si el usuario deniega |
| 5. Justificar en la tienda | Explica el uso de cada permiso sensible en Play Console |
| 6. Revisar antes de publicar | Escanea el build para detectar permisos excesivos |
Minimizar no significa quitar funciones, sino asegurarte de que cada permiso peligroso paga su sitio. Si una librería exige un permiso que tu app no necesita, evalúa si esa librería vale el acceso que reclama. A veces existe una alternativa que cumple el mismo caso de uso sin tocar datos sensibles, como sugiere la propia documentación de Android al recomendar buscar otra vía antes de pedir un permiso.
Permisos, OWASP MASVS y buenas prácticas
El estándar OWASP MASVS recoge la minimización de permisos como una buena práctica de seguridad de plataforma. La idea central coincide con la de Android: pedir solo lo necesario, solicitarlo lo más tarde posible en el flujo, y no depender de datos sensibles cuando existe una alternativa. Verificar los permisos de una app frente a MASVS ayuda a detectar accesos excesivos antes de que lleguen a producción.
En la práctica, esto se traduce en tres hábitos. Declarar el mínimo en el manifiesto, pedir en tiempo de ejecución justo antes de usar el dato, y auditar periódicamente los permisos cuando cambian las funciones o las librerías. Estos hábitos reducen a la vez el riesgo de seguridad y la fricción con la tienda, y evitan la situación incómoda de descubrir un permiso de más cuando un revisor pregunta para qué sirve.
Cómo un escáner ayuda a auditar permisos
La forma más rápida de saber qué permisos declara realmente tu app es analizar el build, no confiar en la memoria. Un análisis del .apk o del .aab muestra los permisos peligrosos presentes, incluidos los que añaden las librerías sin que te des cuenta, y los relaciona con otras posibles configuraciones de riesgo.
Un escáner como PTKD.com analiza el build antes de publicarlo y devuelve un informe mapeado a OWASP MASVS que señala permisos excesivos, secretos incrustados y otras configuraciones de riesgo. Conviene ser honesto sobre su límite: un escáner puede decirte qué permisos declaras, pero no puede decidir por ti cuáles necesita de verdad tu app, porque eso es una decisión de diseño. Lo que sí hace es darte la lista completa y las señales de riesgo para que tomes esa decisión con datos, y no descubras un permiso de más cuando la tienda pregunte por él. En otras palabras, es la diferencia entre auditar tu propia app con datos concretos y enterarte de un problema cuando ya está en manos de un revisor, cuando corregirlo cuesta un ciclo entero.
Puntos clave
- Un permiso "peligroso" es un permiso de tiempo de ejecución que protege datos sensibles y requiere el consentimiento del usuario.
- Las categorías clave son ubicación, cámara, micrófono, contactos, SMS y teléfono, almacenamiento, sensores corporales y calendario.
- Declara y solicita solo el mínimo; cada permiso de más amplía el riesgo y las preguntas de la tienda.
- Pídelos en tiempo de ejecución justo antes de usarlos y maneja el caso en que el usuario los deniegue.
- Antes de publicar, revisa los permisos del build con PTKD.com para detectar accesos excesivos.
