Componentes del manifiesto: cuáles quedan expuestos y a quién

Un componente exportado puede ser invocado por otras aplicaciones del teléfono. No es malo en sí: la pantalla de arranque tiene que estarlo para que el lanzador la abra. Lo que hace peligroso a un componente exportado es no pedir nada a quien lo llama: sin un permiso que lo proteja, cualquier aplicación instalada, incluida una que el usuario descargó ayer de una fuente dudosa, puede lanzarlo o consultarlo.

La documentación oficial fija el valor por omisión según la clase de componente y el nivel de API. Para una actividad sin filtros de intención el valor por omisión es no exportada, y desde Android 12 una app que apunta a ese nivel debe declarar el atributo de forma explícita cuando hay filtros. Por eso la revisión no confía en omisiones: lee el atributo, y si falta, lo anota como dato por aclarar.

Los proveedores de contenido ofrecen datos estructurados a otras aplicaciones a través de direcciones que empiezan por content. Cuando un proveedor está exportado sin permiso de lectura ni de escritura, cualquier aplicación puede consultarlo y, si el proveedor lo permite, modificarlo. Es la clase de componente donde el daño directo sobre datos es mayor, porque el contenido ya viene listo para consumir.

Para una revisión, un proveedor exportado se evalúa por lo que contiene y por si hay permisos que lo protejan. Si además concede permisos temporales sobre sus direcciones, la superficie crece. Contrasta con el proveedor de archivos que comparte un PDF concreto: no exportado, y la concesión es explícita, archivo por archivo.

Un receptor de difusiones atiende avisos identificados por una acción. Si está exportado y sin permiso, cualquier aplicación puede enviarle una difusión con esa acción. Si la acción representa un hecho de negocio, como un pago confirmado, el receptor corre el riesgo de actuar sobre un aviso falso: marcar un recibo como pagado porque alguien lo dijo.

El análisis se centra en dos preguntas: qué acción lo dispara y qué hace el receptor al recibirla. La acción se lee del filtro de intención del manifiesto. La corrección habitual es no exportarlo, o protegerlo con un permiso propio de firma, y comprobar en el código que el aviso es verosímil antes de actuar.

Un buen informe no marca todo lo exportado. Hay exposiciones que el diseño necesita y están bien resueltas: la pantalla de arranque, un receptor que atiende un aviso del propio sistema, un servicio que solo atiende a quien tiene un permiso de la empresa. Reportarlas como fallo hace perder credibilidad al informe y entierra los hallazgos reales.

El criterio es el mismo que se aplicó en la sala de banderas del manifiesto: se reporta lo que está mal, y lo correcto se menciona como revisado. Para un componente exportado, lo correcto es que tenga una razón de ser y que exija algo a quien lo llama cuando maneja algo sensible.

Un proveedor de contenido se identifica por su autoridad, el nombre que aparece en las direcciones content de sus datos. La autoridad es lo que cualquier otra aplicación necesita para consultarlo, así que va en el hallazgo: sin ella, el desarrollador no sabe de qué componente se habla. El resto del hallazgo sigue el formato de la ruta: qué es, dónde está, qué permite a un tercero, su severidad y su corrección.

Aquí la severidad es alta: datos de recibos accesibles sin ninguna condición. La corrección es no exportarlo, o exigir un permiso de firma, y limitar los permisos temporales a lo imprescindible.