Session 06: Security for PMs — Auth, OWASP, and Data Privacy

Part 1: Authentication and Authorization — The foundation of every feature that touches data

Everything you've learned — API endpoints, database queries, deployment pipelines — has an attack surface. This session won't turn you into a security engineer, but it'll keep you from accidentally opening a hole when you write a spec.

Two concepts, one common mistake

You arrive at an office building. The guard at the gate checks your employee badge — that's authentication (verifying identity). But once you're inside, you can't walk into just any room — the server room is IT-only, the finance room is for accounting only. That's authorization (governing access rights).

Authentication asks "who are you?" — the process of verifying identity. Logging in with a username/password, authenticating with an OAuth token, verifying a JWT — all of that is authentication.

Authorization asks "what are you allowed to do?" — once it knows who you are, the system decides whether you have the right to access a specific resource.

Most security bugs in web apps aren't authentication bugs. Login flows are usually tested thoroughly. The bugs live in authorization — and they usually trace back to a spec that was unclear about ownership and permissions.

Role-Based Access Control (RBAC) — Permissions by role

Many products need to grant permissions by role: an admin has different rights than a regular user, a seller has different rights than a buyer. RBAC (Role-Based Access Control) is how you organize this — instead of granting rights to each individual person, you grant rights to each role, then assign roles to users.

Role: admin   → Permissions: read:all, write:all, delete:all
Role: seller  → Permissions: read:own-products, write:own-products, read:own-orders
Role: buyer   → Permissions: read:own-orders, write:own-cart

When a PM designs a feature with multiple roles, the acceptance criteria have to include a test case for each role:

• A buyer tries to delete a product → must be denied
• A seller tries to view another seller's orders → must be denied
• An admin views everything → allowed

If it isn't spec'd out clearly, devs typically only implement the happy path — the feature works for the user who has the right — and skip the cases where the user doesn't.

Part 2: OWASP Top 10 — Through a PM's lens

OWASP (Open Web Application Security Project) is a non-profit focused on web application security. They publish the "Top 10" list — the ten most common and dangerous web vulnerabilities — updated periodically and treated as an industry standard.

IDOR — The bug that starts with a spec missing an ownership check

IDOR (Insecure Direct Object Reference) is the most common bug in web applications. Say you order something online and get an order-tracking link like /orders/1001. If you try changing it to /orders/1002, do you see someone else's order? If you do — that's IDOR. And a big chunk of the root cause comes from unclear requirements.

A simple test for every spec: if you swap the ID in the URL/request for another user's ID, what happens? If the spec doesn't answer that question, the spec isn't done.

It's not just GET APIs. IDOR happens with PUT, PATCH, and DELETE too:

• PUT /users/123/address — can user 456 change user 123's address?
• DELETE /posts/789 — can only the post's author delete it, or any logged-in user?
• GET /invoices/export?id=456 — who can export this invoice?

SQL Injection — Validate input, always

Picture a search box on a website. Normally a user types "blue shirt" and the system finds blue shirts. But if an attacker types a special piece of code instead of a keyword, the system might accidentally execute that code directly against the database — that's SQL injection.

SQL injection happens when user input is spliced directly into a SQL query instead of using parameterized queries (queries with safe, bound parameters). The consequence: the attacker can read, modify, or delete the entire database.

PMs accidentally set the stage for SQL injection when they spec a complex search or filter feature without mentioning input validation. "A user can search by any keyword" isn't a complete spec. You need to add: "Input must be validated and sanitized. Use parameterized queries."

XSS — Rich text and user-generated content

XSS (Cross-Site Scripting) is most dangerous with user-generated content features: comments, reviews, bios, posts. Say someone writes a malicious piece of JavaScript into a comment box. If the system doesn't filter it out, that code runs in the browser of everyone who reads the comment — it can steal a session, redirect to a fake site, or log keystrokes.

The consequences can include: stealing the session cookie (logging in as the victim), redirecting to a phishing site, keylogging.

When you spec a "user can write a bio with rich text (bold, italic, links)" feature, the acceptance criteria have to include: "Sanitize the HTML input, allow only specific tags (b, i, a), strip all unnecessary attributes, disallow <script> and event handlers (onclick, onload)."

Part 3: GDPR and Data Privacy — Product decisions with legal consequences

GDPR (General Data Protection Regulation) is the European Union's personal data protection law, in effect since 2018. The key point is that it applies to any product serving EU users — whether your company is based in Vietnam or anywhere else. The maximum fine can reach 4% of global revenue or 20 million euros.

GDPR's foundational principles

Data minimization: Collect only the data truly necessary for the stated purpose. For example, if all you need is to ship an order, you don't need the user's date of birth. Don't collect "just in case we need it later."

Purpose limitation: Data collected for purpose A can't be used for purpose B without fresh consent. Example: an email collected to confirm an order can't automatically be used to send marketing newsletters.

Storage limitation: Don't keep data longer than necessary. You need a data retention policy and automatic deletion. Example: login logs don't need to be kept for 5 years.

Right to be forgotten: A user has the right to request that all their personal data be deleted. A "delete account" feature has to actually delete (or anonymize) the data, not just deactivate the account.

Product decisions that need legal review

Before designing the following features, a PM should consult with legal/compliance:

• Collecting biometric data (facial recognition, fingerprints)
• Continuous location tracking
• Sharing user data with third-party partners
• Remarketing and ad tracking
• Collecting data from children under 16
• Cross-border data transfer (EU users' data stored on servers outside the EU)

Consent is not a checkbox

Consent under GDPR has to be:

• Freely given: No coercion. Example: making the app unusable unless the user agrees to marketing data collection is a violation.
• Specific: One purpose at a time — you can't bundle everything into a single checkbox.
• Informed: The user has to understand what they're agreeing to — in plain language, not legalese.
• Unambiguous: An active opt-in, not opt-out. A pre-checked checkbox is invalid.
• Withdrawable: Withdrawing consent has to be as easy as giving it.

Part 4: Writing Security Requirements

Security is not an afterthought

"We'll deal with security later" is the most expensive sentence in product development. Picture building a house: installing the door locks before you paint the walls is easy. But if the wall is already built and only then you remember you need to run wiring for a smart lock — you have to break the wall open, re-run the wire, re-plaster, repaint. Security built into the spec from the start is many times cheaper than retrofitting it after the code exists.

A template for acceptance criteria that include security:

Feature: [Feature name]

Happy path:
- Authorized user + valid request → [expected result]

Security cases:
- No auth token → 401 Unauthorized
- Expired token → 401, redirect to login
- Valid token but no rights to the resource → 403 Forbidden
- Valid token, has rights, but resource doesn't exist → 404 Not Found
- Invalid input (wrong format, out of range) → 400 Bad Request with a clear error message
- Sensitive data not exposed in the response (passwords, other users' internal IDs)

A security checklist question for every feature

Before you finalize a spec, run through this checklist:

• Ownership: Who owns this resource? Can someone access another person's resource?
• Input: Is all user input validated? Does any feature process HTML/JavaScript from users?
• Data exposure: Does the response contain sensitive data that isn't needed?
• Rate limiting: Can this endpoint be abused (password brute forcing, data scraping)? Does it need a rate limit?
• Audit trail: Does this sensitive action need to be logged? (Deleting data, changing permissions, admin access)
• Privacy: Does this feature collect new user data? Is consent needed?

Further reading

• OWASP Top 10 — The list of the 10 most common web security vulnerabilities, updated periodically by the global security community.
• OWASP Juice Shop — A deliberately vulnerable web app for learning security hands-on. Free, runs on your own machine.
• GDPR.eu — What is GDPR? — An explanation of GDPR in plain language, covering user rights and organizational obligations.
• PortSwigger Web Security Academy — A free web security course with hands-on labs for IDOR, XSS, SQL injection, and many other vulnerabilities.
• Troy Hunt — Have I Been Pwned — Understand why data breaches happen and their real impact on users.