Logging is how you debug an app, and it is also how sensitive data quietly leaks out of it. A log line that prints an auth token, a password, or a full API response feels harmless during development, but those logs can be read off the device, swept into crash reports, or left enabled in your release build where anyone with access can see them. Insecure logging is a recognized mobile risk precisely because it is so easy to do by accident. Here is why it matters, what ends up in logs without you meaning to, and how to log without leaking.
Short answer
Insecure logging means writing sensitive data, tokens, passwords, personal information, or full request and response bodies, to the device's logs, where it can be exposed. Per OWASP MASVS, app logs can be read by tools with device access, captured in crash reports and diagnostics, and on older Android by other apps, so sensitive values in logs are a real leak. The fix is to never log sensitive data, strip or disable verbose and debug logging in release builds, redact anything sensitive that must be logged, and check that crash reporters and network loggers are not capturing payloads. Treat logs as readable output, not a private space.
What you should know
- Logs are not private: they can be read with device or diagnostic access.
- Sensitive data does not belong in logs: tokens, passwords, personal data.
- Release builds should be quiet: strip verbose and debug logging.
- Crash reporters capture data: they may sweep up logged values.
- Network loggers log payloads: full request and response bodies leak.
Why is logging sensitive data a risk?
Because logs leave the safety of your code and become readable output. Anything your app writes to the system log can be accessed in several ways: a developer or attacker with device access can read it, diagnostic and bug-report exports include it, crash-reporting services often attach recent logs to reports, and on older Android versions other apps could read the shared log. So a token or password printed to the log is no longer contained in your running app; it sits in a place other parties can reach. The reason this is such a common finding is that the logging that exposes it was usually added for legitimate debugging and simply never removed, so an app that runs perfectly can still be spilling sensitive values into its logs the whole time.
What ends up in logs by accident?
More than developers expect, usually through convenience logging. The table lists the common culprits.
| Source | What it leaks |
|---|---|
| Debug logging left in release | Whatever you logged during development |
| Logging full API requests and responses | Tokens, credentials, and personal data in payloads |
| Exception and crash logging | Sensitive values present at the point of failure |
| Network inspection libraries | Complete request and response bodies |
| Logging user input or state | Passwords, messages, and other personal data |
The recurring theme is that the data was logged to help debugging and then forgotten. Logging an entire HTTP response to diagnose an issue, then shipping that code, means every response, including any tokens or personal data it carried, goes to the log in production. Likewise, a network inspection library that prints full payloads is fine in development and a leak in release.
How do you log safely?
Keep sensitive data out of logs, and make release builds quiet. The first rule is simply not to log sensitive values, tokens, passwords, keys, personal data, at all; if you must log around them, redact or omit the sensitive parts rather than printing the whole object or response. Use log levels properly and disable verbose and debug logging in release builds, so the detailed logging that is useful in development does not ship. Review your crash reporter and any network inspection or HTTP logging library to confirm they are not capturing payloads or attaching sensitive logs in production, and configure them to redact. The principle is that what is acceptable to log in a debug build is often not acceptable in release, so the release build should log only what is safe for anyone to read.
What to watch out for
The first trap is verbose or debug logging left enabled in the release build, which keeps printing whatever you logged during development. The second is logging full requests and responses, which sweeps up tokens and personal data in the payloads. The third is a crash reporter or network logger quietly capturing sensitive values; review their configuration. A pre-submission scan such as PTKD.com (https://ptkd.com) reads the compiled APK, AAB, or IPA against OWASP MASVS and surfaces logging behavior and sensitive data handling, so you can catch a release build that logs sensitive information before it ships. Removing the sensitive logging and quieting release builds is the fix.
What to take away
- Insecure logging writes sensitive data to logs that can be read with device access, captured in crash reports, or, on older Android, read by other apps.
- The common cause is debug logging or full request and response logging left in the release build, plus crash and network loggers capturing payloads.
- Never log sensitive values, redact what must be logged, and disable verbose and debug logging in release builds.
- Review your crash reporter and network loggers, and use a pre-submission scan such as PTKD.com to catch sensitive data in your app's logging before launch.
