Skip to content

Conversation

Copy link
Contributor

Copilot AI commented Jan 31, 2026

MASTG-KNOW-0101 previously covered only Apple's standard logging APIs (NSLog, print, Logger, os_log). Developers introduce logs through additional mechanisms that should be documented for comprehensive security testing.

Changes

Added "Additional Logging Sources" section documenting four logging vectors:

  • Native Libraries: C/C++ libraries writing to stdout/stderr via printf, fprintf - outputs appear in device logs when integrated into iOS apps

  • Crash Reporting Tools: Services like Crashlytics, Sentry record logs/breadcrumbs/contextual data to disk before upload, creating persistent records that outlive app sessions

  • Networking/HTTP Clients: Verbose/debug modes that log headers, URLs, response bodies, auth tokens - risk exposure when inadvertently enabled in production

  • WebView Console: JavaScript console.* methods bridged to native logging via WKScriptMessageHandler for WKWebView

Content maintains knowledge-file convention: descriptive (not prescriptive), no security testing implications, no remediation advice.

Original prompt

This section details on the original issue you should resolve

<issue_title>Update MASTG-KNOW-0101 with more logging options </issue_title>
<issue_description>Any other ways that devs could introduce logs? E.g. 3rd party libs that might use different system apis?

Originally posted by @Diolor in #3588 (comment)

Consider and validate with real examples:

  • Lower level native libraries written in C or C plus plus may write directly to stdout or stderr using functions like printf or fprintf. These outputs can appear in device logs, especially during development and debugging sessions.

  • Crash reporting and error monitoring tools may record logs or breadcrumbs to disk and upload them later. This creates persistent records that can outlive a single app session and may include contextual data if not carefully filtered.

  • Networking stacks and HTTP clients sometimes provide verbose or debug logging modes that dump headers, URLs, or payloads. If enabled outside of debug builds, these logs can expose credentials or personal data.

  • Apps that embed web content can also receive logs from JavaScript runtimes and WebViews through console logging. These messages are often bridged into native logging systems.

</issue_description>

Comments on the Issue (you are @copilot in this section)

@cpholguera It's assigned to you @Tarini-Ag , thank you. @cpholguera @hharshhsaini you can, but please carefully read the contribution guidelines:

https://mas.owasp.org/contributing/#what-not-to-do

And consider the previously closed PR.</comment_new>


✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

- Document native C/C++ libraries logging via stdout/stderr
- Add crash reporting and error monitoring tools section
- Document networking stacks and HTTP clients verbose logging
- Add WebViews and JavaScript console logging section

Co-authored-by: cpholguera <[email protected]>
Copilot AI changed the title [WIP] Update MASTG-KNOW-0101 with additional logging options Expand MASTG-KNOW-0101 with third-party and indirect logging mechanisms Jan 31, 2026
Copilot AI requested a review from cpholguera January 31, 2026 22:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Update MASTG-KNOW-0101 with more logging options

2 participants