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.

Flag Disclosure-Specific Behavior

--scope

Default changed . Focuses on files handling personal data: API handlers, data models, logging, caching, third-party integrations, and error handling.

--depth quick

Grep patterns only: scan for PII in logs, error messages, and third-party data sharing.

--depth standard

Full code read, trace personal data flows within each file, check access controls on personal data stores.

--depth deep

Cross-file personal data flow tracing. Map all paths where PII exits the application boundary.

--depth expert

Deep + breach simulation: model what personal data is exposed in each attack scenario.

--severity

Filter output. PII in logs is typically high ; over-fetching is medium .

--fix

Generate redaction, field-level access control, and data minimization replacements.

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

• Parse --scope flag (default: changed ).

• Resolve to a concrete file list.

• Filter to relevant files: API handlers, data models, logging configuration, error handling, caching logic, third-party SDK integrations, data export endpoints, and serialization logic.

• 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:

• Check logging for PII: Scan log statements for personal data fields (name, email, phone, address, SSN, health data, financial data).

• Assess API response data: Determine whether endpoints return more personal fields than the consumer needs (over-fetching).

• Examine third-party data sharing: Identify where personal data flows to external services (analytics, advertising, logging, error tracking).

• Check error handling: Look for personal data in error messages, stack traces, and debug output.

• 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

• Do log statements include personal data (names, emails, phone numbers, addresses)?

• Are API responses returning full user objects instead of only needed fields?

• Is personal data sent to third-party analytics or error tracking services?

• Do error messages or stack traces contain personal data values?

• Is PII passed through URL query parameters (visible in logs and referrer headers)?

• Are personal data fields encrypted at rest, or stored in plaintext?

• Do caching layers store personal data without appropriate TTLs or access controls?

• Do debug modes expose additional personal data that production would not?

What to Look For

• 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

• Over-fetched API responses: Returning complete user objects with unnecessary fields.

• Grep: res.json(user)|response.send(userData)|SELECT *.*FROM.*user|.toJSON()

• 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

• PII in error responses: Personal data leaked through error handling.

• Grep: res.status(.*.json(.*user|catch.*res.send(.*err|error.*message.*email

• Personal data in URLs: PII in query parameters or path segments.

• Grep: ?email=|&phone=|/users/${email}|encodeURIComponent(.*email)|queryString.*ssn

• Plaintext PII storage: Personal data stored without encryption.

• Grep: password.*varchar|ssn.*text|credit_card.*string|healthData.*column|plaintext.*pii

• Cache with personal data: PII stored in cache layers without protection.

• Grep: cache.set(.*user|redis.set(.*email|localStorage.setItem(.*token|sessionStorage.*user

• Missing field-level access control: No column or field restriction on personal data.

• Grep: SELECT *|findAll()|.find({})|.aggregate([|include:.*all

Regulatory Mapping

Regulation Provision Relevance

GDPR Art. 5(1)(f) Integrity and confidentiality Personal data must be protected against unauthorized disclosure

GDPR Art. 32 Security of processing Appropriate technical measures to protect personal data

GDPR Art. 33-34 Breach notification Disclosure of personal data triggers 72-hour notification

CCPA 1798.100 Right to know Consumers must know what personal data is collected and shared

CCPA 1798.150 Private right of action Data breaches exposing personal data create liability

HIPAA 164.312 Technical safeguards Protected health information requires access controls and encryption

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:

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