MobSF analyzes mobile applications and exposes a REST API for integration with CI/CD and security workflows. The service accepts application packages, source archives and related artifacts, parses them and stores reports. That makes it a useful analysis tool and a high-risk upload endpoint if it is reachable by untrusted users.

On 2026-11-07, a count-only query for app="MobSF" matched 577 public assets. The title query returned 941 and a body keyword returned 849,499. The huge body count is a clear example of broad text matching. The app observation is narrower, but it still does not show whether the API is public, authenticated or processing untrusted files.

Treat uploads as hostile input

Every uploaded application is an untrusted parser input. Run MobSF in an isolated environment with a dedicated service identity, restricted outbound access and a separate storage path. Do not mount the host Docker socket or broad credentials into the scanner. Keep scan artifacts separate from source-code repositories and production secrets.

Set file-size and concurrency limits. Monitor disk use because scan reports and decompressed artifacts can consume storage. Clean up old scans according to a retention policy, and make sure the cleanup process cannot follow symlinks outside the intended directory.

Protect the API

MobSF documentation says the REST API requires an API key, including deployments where the web authentication setting is changed. Use the API-only mode when a web console is not needed. Put the service behind a network policy or authenticated gateway, and restrict API clients to the CI runners that need it.

Do not rely on a default login. The Docker quick-start documentation calls out default credentials for initial use. Change them before exposing the service, and review whether registration or user administration is enabled. Store the API key in the CI secret system rather than in job logs.

Review the output boundary

Scan reports can include package names, permissions, URLs, hardcoded strings, certificates and source snippets. Treat the report as sensitive data. Restrict download routes, expiry and access logs. If reports are copied to a ticket or wiki, remove credentials and personal data before sharing.

Test the API with an authorized test artifact. Confirm authentication failure, upload success and report retrieval for the intended client. Then try a disallowed file type and an oversized file. Check that errors do not reveal internal paths or credentials.

Use the measurement as a lead

The app count helps locate visible MobSF installations for an exposure review. It does not prove that the service accepts anonymous uploads or that a particular version is vulnerable. Verify the endpoint and authentication state with the asset owner.

An external scan service is only as safe as its isolation and its data-handling policy. Keep the parser away from production networks, protect the API key and treat every report as untrusted output that may contain sensitive application material.

References