Disclosure of Information Analysis (LINDDUN D2)

Analyze source code for disclosure threats where personal data is accessible to unauthorized parties. Focuses specifically on personal and sensitive data rather than general system information. Covers direct disclosure (data breach vectors) and indirect disclosure (third-party sharing, over-collection).

Supported Flags

Read ../../shared/schemas/flags.md for full flag documentation. This skill supports all cross-cutting flags.

Framework Context

LINDDUN D2 -- Disclosure of Information

Disclosure of information in the LINDDUN context refers specifically to unauthorized access to personal data. Read ../../shared/frameworks/linddun.md for the full LINDDUN framework reference including the distinction between LINDDUN disclosure (personal data focus) and STRIDE information disclosure (general system information).

Privacy Property Violated: Confidentiality of Personal Data

STRIDE Mapping: Information Disclosure (LINDDUN narrows focus specifically to personal data rather than general system information)

Workflow

Step 1 -- Determine Scope

1. Parse --scope flag (default: changed).
2. Resolve to a concrete file list.
3. Filter to relevant files: API handlers, data models, logging configuration, error handling, caching logic, third-party SDK integrations, data export endpoints, and serialization logic.
4. Prioritize files containing: user data structures, PII fields, third-party API calls with user data, log statements, cache writes, and error responses.

Step 2 -- Analyze for Personal Data Disclosure

Read each scoped file and assess personal data exposure vectors:

1. Check logging for PII: Scan log statements for personal data fields (name, email, phone, address, SSN, health data, financial data).
2. Assess API response data: Determine whether endpoints return more personal fields than the consumer needs (over-fetching).
3. Examine third-party data sharing: Identify where personal data flows to external services (analytics, advertising, logging, error tracking).
4. Check error handling: Look for personal data in error messages, stack traces, and debug output.
5. Evaluate cache and temporary storage: Determine whether personal data in caches, temp files, or browser storage is properly protected.

At --depth deep or --depth expert, trace all paths where personal data exits the application boundary and map the full disclosure surface.

Step 3 -- Report Findings

Output findings per ../../shared/schemas/findings.md. Each finding needs: DDSCL-NNN id, title, severity (based on data sensitivity and exposure scope), location with snippet, description of what personal data is disclosed and through which channel, impact (unauthorized data access), fix (redaction, minimization, or encryption), and CWE/LINDDUN references.

Analysis Checklist

1. Do log statements include personal data (names, emails, phone numbers, addresses)?
2. Are API responses returning full user objects instead of only needed fields?
3. Is personal data sent to third-party analytics or error tracking services?
4. Do error messages or stack traces contain personal data values?
5. Is PII passed through URL query parameters (visible in logs and referrer headers)?
6. Are personal data fields encrypted at rest, or stored in plaintext?
7. Do caching layers store personal data without appropriate TTLs or access controls?
8. Do debug modes expose additional personal data that production would not?

What to Look For

1. PII in log statements: Personal data written to logs, console, or debug output.
   • Grep: log\.\w+\(.*email|logger\.\w+\(.*password|console\.log\(.*ssn|print\(.*credit.card
2. Over-fetched API responses: Returning complete user objects with unnecessary fields.
   • Grep: res\.json\(user\)|response\.send\(userData\)|SELECT \*.*FROM.*user|\.toJSON\(\)
3. Third-party data sharing: PII sent to analytics, error tracking, or advertising SDKs.
   • Grep: Sentry\.captureException.*user|analytics\.track.*email|gtag.*user_id|bugsnag.*user
4. PII in error responses: Personal data leaked through error handling.
   • Grep: res\.status\(.*\.json\(.*user|catch.*res\.send\(.*err|error.*message.*email
5. Personal data in URLs: PII in query parameters or path segments.
   • Grep: \?email=|&phone=|/users/\$\{email\}|encodeURIComponent\(.*email\)|queryString.*ssn
6. Plaintext PII storage: Personal data stored without encryption.
   • Grep: password.*varchar|ssn.*text|credit_card.*string|healthData.*column|plaintext.*pii
7. Cache with personal data: PII stored in cache layers without protection.
   • Grep: cache\.set\(.*user|redis\.set\(.*email|localStorage\.setItem\(.*token|sessionStorage.*user
8. Missing field-level access control: No column or field restriction on personal data.
   • Grep: SELECT \*|findAll\(\)|\.find\(\{\}\)|\.aggregate\(\[|include:.*all

Regulatory Mapping

Output Format

Use finding ID prefix DDSCL (e.g., DDSCL-001, DDSCL-002).

All findings follow the schema in ../../shared/schemas/findings.md with:

• references.cwe: CWE-200, CWE-311, or CWE-532 as appropriate
• references.owasp: A01:2021 (Broken Access Control) or A02:2021 (Cryptographic Failures)
• metadata.tool: "data-disclosure"
• metadata.framework: "linddun"
• metadata.category: "D2"

Summary table after all findings:

| Disclosure Pattern           | Critical | High | Medium | Low |
|------------------------------|----------|------|--------|-----|
| PII in logs                  |          |      |        |     |
| Over-fetched API responses   |          |      |        |     |
| Third-party data sharing     |          |      |        |     |
| PII in error messages        |          |      |        |     |
| Personal data in URLs        |          |      |        |     |
| Plaintext PII storage        |          |      |        |     |
| Cache / temp storage leaks   |          |      |        |     |

Followed by: top 3 priorities, personal data flow map, and overall assessment.