Linkability Analysis (LINDDUN L)

Analyze source code for linkability threats where separate data points, actions, or records can be correlated to the same individual across contexts, services, or time periods — even when the system is fully encrypted and authenticated.

Supported Flags

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

Framework Context

LINDDUN L — Linkability

Linkability occurs when an adversary can determine that two or more items of interest (data records, messages, actions, users) are related, even without knowing the identity of the data subject. Read ../../shared/frameworks/linddun.md for the full LINDDUN framework reference including cross-framework mappings and regulatory context.

Privacy Property Violated: Unlinkability

STRIDE Mapping: Information Disclosure (linkability extends beyond data access to correlation analysis across contexts)

Workflow

Step 1 — Determine Scope

1. Parse --scope flag (default: changed).
2. Resolve to a concrete file list.
3. Filter to relevant files: source code, configuration, database schemas, API definitions, analytics integrations, and cookie/session management.
4. Prioritize files containing: user ID references, session management, analytics event emission, cross-service API calls, database joins across user activity tables.

Step 2 — Analyze for Linkability Patterns

Read each scoped file and check for patterns that enable cross-context correlation of user activity:

1. Identify shared identifiers: Find user IDs, email addresses, device IDs, or tokens that propagate across service boundaries.
2. Trace identifier scope: Determine whether identifiers are context-specific (scoped to one service) or global (shared across services).
3. Check analytics events: Look for events that combine user identity with behavioral data.
4. Examine database schemas: Look for foreign keys and joins that link user activity across tables or services.
5. Assess cookie and session scope: Check whether tracking cookies persist across domains or contexts.

At --depth deep or --depth expert, map the full identifier propagation graph across the codebase and model what correlations an adversary can derive.

Step 3 — Report Findings

Output findings per ../../shared/schemas/findings.md. Each finding needs: LINK-NNN id, title, severity (based on correlation potential and data sensitivity), location with snippet, description of what can be linked, impact (profile an adversary can build), fix (pseudonymization or isolation), and CWE/LINDDUN references.

Analysis Checklist

1. Do different microservices share the same user ID without pseudonymization?
2. Are there cookies or tokens that persist across different application contexts?
3. Do analytics events combine user identity with detailed behavioral data?
4. Can database tables be joined to correlate user activity across features?
5. Are device fingerprints (user agent, screen resolution, fonts) collected?
6. Do API responses include identifiers that allow cross-endpoint correlation?
7. Are session identifiers rotated, or do they persist across long time periods?
8. Can pseudonymized datasets be re-linked through common timestamps or IPs?

What to Look For

1. Global user IDs across services: userId, user_id, accountId passed between microservices without per-service pseudonyms.
   • Grep: userId|user_id|accountId|account_id in API call payloads and headers
2. Cross-domain tracking cookies: Cookies with broad domain scope or third-party cookie setting.
   • Grep: document\.cookie|Set-Cookie|domain=\.|SameSite=None
3. Device fingerprinting: Collection of browser or device attributes for identification.
   • Grep: navigator\.userAgent|screen\.width|screen\.height|navigator\.plugins|canvas\.toDataURL|fingerprint
4. Analytics with user identity: Events that include both user ID and behavior.
   • Grep: analytics\.track|analytics\.identify|gtag\(|mixpanel\.track|segment\.track
5. Database joins on user tables: Queries that correlate user activity across domains.
   • Grep: JOIN.*user|JOIN.*account|INNER JOIN.*activity|LEFT JOIN.*session
6. Persistent identifiers in URLs: User IDs, email addresses, or tokens in URL paths or query parameters that appear in logs and referrer headers.
   • Grep: req\.params\.userId|req\.query\.email|/users/\$\{|/api/.*userId=
7. Log correlation: Log entries that combine user identity with action metadata.
   • Grep: logger\.\w+\(.*userId|log\.\w+\(.*user_id|console\.log\(.*email

Regulatory Mapping

Output Format

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

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

• references.cwe: CWE-359 or CWE-212 as appropriate
• references.owasp: A01:2021 (Broken Access Control — cross-context leakage)
• metadata.tool: "linking"
• metadata.framework: "linddun"
• metadata.category: "L"

Summary table after all findings:

| Linkability Pattern    | Critical | High | Medium | Low |
|------------------------|----------|------|--------|-----|
| Cross-service IDs      |          |      |        |     |
| Tracking cookies       |          |      |        |     |
| Device fingerprinting  |          |      |        |     |
| Analytics correlation  |          |      |        |     |
| Database joins         |          |      |        |     |
| Log correlation        |          |      |        |     |

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