Principles of Product Management: Security & Privacy (Auth, OAuth, OWASP Top 10, GDPR, CCPA, Data Minimization)

Security & Privacy (Auth, OAuth, OWASP Top 10, GDPR, CCPA, Data Minimization)

Security & Privacy for Product Managers: A Practical Study Guide

What This Is

Security and privacy aren’t just compliance checkboxes—they’re core product pillars that build trust, reduce churn, and prevent catastrophic breaches (e.g., Equifax’s $700M GDPR fine, Facebook’s Cambridge Analytica scandal). For PMs, this means designing features with security/privacy in mind, not bolting them on later.
Example: When Stripe launched "Stripe Identity" (a KYC tool for fintechs), they had to balance frictionless onboarding (OAuth for quick logins) with fraud prevention (OWASP Top 10 mitigations) and GDPR compliance (data minimization, right to erasure). A misstep here could mean losing users or regulators.

Key Terms & Frameworks

1. Authentication (Auth) vs. Authorization
2. AuthN: Proving who you are (e.g., username/password, biometrics).
3. AuthZ: What you’re allowed to do (e.g., "Can this user edit this doc?").

4. Real-world: Slack’s "Sign in with Google" uses OAuth for AuthN; role-based access (Admin/Guest) is AuthZ.

5. OAuth 2.0 (Open Authorization)

6. A delegation protocol letting users grant apps access to their data without sharing passwords (e.g., "Log in with Facebook").
7. Flows: Authorization Code (web apps), Implicit (legacy, deprecated), PKCE (mobile apps).

8. Example: Spotify uses OAuth to let users import playlists from Apple Music.

9. OWASP Top 10 (2021)

10. The 10 most critical web app security risks, ranked by exploitability/impact. Must-know for PMs:
    1. Broken Access Control (e.g., users accessing others’ data via URL manipulation).
    2. Cryptographic Failures (e.g., storing passwords in plaintext).
    3. Injection (e.g., SQL/NoSQL attacks).
    4. Insecure Design (e.g., no rate-limiting on login attempts).

11. PM’s role: Ensure engineers use OWASP’s Cheat Sheet Series for mitigations.

12. GDPR (General Data Protection Regulation)

13. EU law (2018) giving users rights over their data (e.g., access, deletion, portability). Fines: 4% of global revenue or €20M, whichever is higher.
14. Key principles:
    • Lawful basis (consent, contract, legal obligation).
    • Data minimization (collect only what’s necessary).
    • Right to erasure ("forget me").

15. Example: Airbnb’s GDPR compliance includes a "Download My Data" feature and granular consent toggles.

16. CCPA (California Consumer Privacy Act)

17. California’s GDPR-lite (2020). Key differences:
    • Applies to businesses with $25M+ revenue or 50K+ users.
    • Users can opt out of data sales (vs. GDPR’s opt-in consent).
    • No "right to correction" (unlike GDPR).

18. Example: Google’s "Ad Personalization" toggle lets users opt out of CCPA data sales.

19. Data Minimization

20. Collect only the data you need for the feature’s purpose. Why? Less data = less risk (breaches, misuse, compliance violations).
21. Formula:
    Data Collected = Minimum Viable Data (MVD) + Optional Data (with user consent)

22. Example: Uber’s "Ride Receipts" only store trip start/end points, not full GPS trails.

23. Zero Trust Architecture

24. "Never trust, always verify"—assume every request (internal or external) is a threat. Key components:
    • Identity verification (MFA, device posture checks).
    • Least-privilege access (users get only the permissions they need).
    • Micro-segmentation (isolate systems, e.g., payment processing from marketing).

25. Example: Google’s BeyondCorp (replaced VPNs with identity-based access).

26. Privacy by Design (PbD)

27. 7 Foundational Principles (Ann Cavoukian, 2010):
    1. Proactive, not reactive.
    2. Privacy as the default setting.
    3. Embedded into design.
    4. Full functionality (no trade-offs).
    5. End-to-end security.
    6. Visibility and transparency.
    7. Respect for user privacy.

28. Example: Apple’s App Tracking Transparency (ATT) forces apps to ask for permission before tracking users.

29. Security vs. Privacy

30. Security: Protecting data from unauthorized access (e.g., encryption, firewalls).
31. Privacy: Protecting users’ rights to control their data (e.g., consent, anonymization).

32. Trap: "We’re secure, so we’re private" → False. A hacked database is a security failure; selling user data without consent is a privacy failure.

33. Threat Modeling (STRIDE)

    
    
    • Microsoft’s framework to identify security threats early. Categories:
    • Spoofing (fake identities).
    • Tampering (data alteration).
    • Repudiation (denying actions).
    • Information disclosure (data leaks).
    • Denial of Service (DoS).
    • Elevation of Privilege (unauthorized access).
    • PM’s role: Run a STRIDE workshop with engineers before building a feature (e.g., "What if a user spoofs their location in our ride-hailing app?").

34. DPIA (Data Protection Impact Assessment)

    
    
    • GDPR-mandated risk assessment for high-risk processing (e.g., large-scale biometrics, profiling).
    • Steps:
    • Describe the processing.
    • Assess necessity/proportionality.
    • Identify risks.
    • Mitigation measures.
    • Example: A health app using facial recognition for mood tracking would need a DPIA.

35. Security ROI Formula

    
    
    • ROI = (Risk Reduction – Cost of Control) / Cost of Control
    • Variables:
    • Risk Reduction: Expected loss from a breach (e.g., $10M) × reduction % (e.g., 90%).
    • Cost of Control: Implementation cost (e.g., $1M for encryption).
    • Example: If a breach costs $10M and encryption reduces risk by 90% ($9M saved), ROI = ($9M – $1M) / $1M = 800%.

Step-by-Step: Applying Security & Privacy in Product Development

1. Map Data Flows Early
2. Action: Draw a data flow diagram (DFD) for your feature (e.g., "How does a user’s email travel from signup to our database?").
3. Tools: Lucidchart, Miro, or OWASP’s Threat Dragon.

4. Example: For a "Save Payment Method" feature, map:
   User → Frontend → API → Tokenization Service → Database.

5. Run a Threat Model (STRIDE)

6. Action: With engineers, brainstorm threats for each DFD component. Ask:
   • Spoofing: Can someone fake being this user?
   • Tampering: Can they alter the payment token?
   • Repudiation: Can they deny making a purchase?

7. Output: A list of mitigations (e.g., "Use OAuth + MFA for AuthN").

8. Design for Privacy by Default

9. Action: Apply data minimization and user control:
   • Default settings should be private (e.g., "Share my location" = OFF).
   • Give users granular controls (e.g., "Delete my search history").

10. Example: DuckDuckGo’s default "no tracking" vs. Google’s opt-out model.

11. Implement AuthN/AuthZ Securely

12. Action: Choose the right auth pattern:
    • OAuth 2.0 + PKCE for mobile/web apps.
    • SAML for enterprise SSO.
    • WebAuthn for passwordless logins (e.g., YubiKey).

13. Avoid: Rolling your own auth (use Firebase Auth, Auth0, or Okta).

14. Validate with Compliance Checklists

15. Action: Use these pre-launch checklists:
    • GDPR: ICO’s Self-Assessment.
    • CCPA: California AG’s Guide.
    • OWASP Top 10: Cheat Sheet Series.

16. Example: Before launching in the EU, check:

    
    
    • Do we have a Data Processing Agreement (DPA) with vendors?
    • Is our cookie banner GDPR-compliant (no pre-ticked boxes)?

17. Monitor & Iterate

18. Action: Set up security metrics and privacy KPIs:
    • Security: % of users with MFA enabled, # of failed login attempts.
    • Privacy: % of users opting out of data sales (CCPA), # of data deletion requests.
19. Example: Twitter’s Transparency Report tracks government data requests.

Common Mistakes

1. Mistake: Treating security/privacy as an "engineering problem."

2. Correction: PMs own the "why" and "what" (e.g., "We need OAuth to reduce friction and improve security"). Partner with engineers early to define requirements (e.g., "Must support PKCE for mobile").

3. Mistake: Assuming GDPR/CCPA only apply to "big tech."

4. Correction: If you have users in the EU/California, you’re in scope. Even startups must comply (e.g., a 10-person SaaS with EU customers needs a DPO and data deletion process).

5. Mistake: Using "security" as an excuse to add friction.

6. Correction: Balance security and UX. Example:

   
   
   • Bad: Forcing 2FA on every login (high friction).
   • Good: Risk-based 2FA (e.g., only for high-value actions like password changes).

7. Mistake: Storing sensitive data "just in case."

8. Correction: Delete data you don’t need. Example:

   
   
   • Bad: Storing full credit card numbers (PCI DSS violation).
   • Good: Use tokenization (e.g., Stripe’s tok_123).

9. Mistake: Ignoring third-party risks.

10. Correction: Vendor security is your security. Example:
    • Bad: Using a random analytics tool without a DPA.
    • Good: Only work with vendors who sign DPAs and pass SOC 2 audits.

PM Interview / Practical Insights

1. Tricky Distinction: "Security vs. Privacy"
2. Interviewer: "How would you design a feature that’s both secure and private?"
3. Trap: Answering with only encryption (security) or only consent (privacy).

4. Answer: "Security protects data from threats (e.g., encrypting payment info), while privacy protects user rights (e.g., letting them delete their data). For a health app, I’d:

   
   
   • Secure data with end-to-end encryption (AES-256) and OAuth 2.0.
   • Privacy by default (e.g., no data sharing without explicit consent) and a GDPR-compliant deletion flow."

5. OWASP Top 10 in Interviews

6. Interviewer: "How would you prevent a data breach in our e-commerce app?"
7. Trap: Vague answers like "use encryption."

8. Answer: "I’d focus on the OWASP Top 3:

   
   
   1. Broken Access Control: Enforce role-based access (e.g., only admins can export user data).
   2. Cryptographic Failures: Never store passwords in plaintext (use bcrypt).
   3. Injection: Sanitize all user inputs (e.g., SQL parameters for search queries)."

9. GDPR/CCPA Trade-offs

10. Interviewer: "A feature requires collecting more user data. How do you decide?"
11. Trap: Saying "just get consent" without considering alternatives.

12. Answer: "I’d ask:

    
    
    • Is this data necessary? (Data minimization)
    • Can we anonymize it? (e.g., aggregate analytics instead of individual tracking)
    • What’s the user benefit? (e.g., personalization vs. creepiness)
    • What’s the compliance risk? (e.g., GDPR fines vs. CCPA opt-outs)."

13. AuthN/AuthZ in System Design

14. Interviewer: "Design a multi-tenant SaaS app with role-based access."
15. Trap: Forgetting to separate AuthN (who you are) from AuthZ (what you can do).
16. Answer: "I’d use:
    • AuthN: OAuth 2.0 + PKCE for mobile, SAML for enterprise SSO.
    • AuthZ: Role-based access control (RBAC) with least privilege (e.g., Viewer vs. Admin roles).
    • Audit logs: Track all access attempts (e.g., "User X tried to delete data at 2:30 PM")."

Quick Check Questions

1. Scenario: Your team wants to add a "Social Login" feature (e.g., "Log in with Google"). What security/privacy risks should you consider?
2. Answer: OAuth 2.0 risks (e.g., token theft, scope creep), third-party data sharing (GDPR/CCPA), and phishing (e.g., fake "Log in with Google" buttons).

3. Why? Social logins introduce dependencies on external providers and expand your attack surface.

4. Scenario: A user requests to delete their account under GDPR. Your engineers say it’ll take 3 months to build. How do you respond?

5. Answer: Push back—GDPR requires deletion within 30 days. Prioritize this as a compliance blocker and scope a minimal solution (e.g., soft-delete first, then hard-delete later).

6. Why? Non-compliance risks fines and reputational damage.

7. Scenario: Your analytics team wants to track user behavior across devices. What’s the privacy-preserving way to do this?

8. Answer: Use anonymous identifiers (e.g., hashed emails) or differential privacy (adding noise to data). Avoid persistent cross-device tracking without explicit consent.
9. Why? GDPR/CCPA require user control over tracking, and Apple’s ATT blocks IDFA-based tracking.

Last-Minute Cram Sheet

1. OAuth 2.0 flows: Authorization Code (web), PKCE (mobile), Implicit (deprecated).
2. OWASP Top 3: Broken Access Control, Cryptographic Failures, Injection.
3. GDPR vs. CCPA: GDPR = opt-in, CCPA = opt-out; GDPR has "right to correction," CCPA doesn’t.
4. Data minimization formula: Data Collected = MVD + Optional (with consent).
5. Zero Trust: "Never trust, always verify" (MFA, least privilege, micro-segmentation).
6. Privacy by Design: 7 principles—default to private, embed in design, end-to-end security.
7. STRIDE: Spoofing, Tampering, Repudiation, Information Disclosure, DoS, Elevation of Privilege.
8. DPIA: Required for high-risk GDPR processing (e.g., biometrics, profiling).
9. Security ROI: (Risk Reduction – Cost of Control) / Cost of Control.
10. ⚠️ Trap: "We’re secure, so we’re private" → Security ≠ Privacy (e.g., encrypted data can still be sold without consent).