How software works · Guide for product managers
Security for product managers
Most security incidents in small and mid-size products are not sophisticated attacks. They are ordinary mistakes — a leaked key, a missing permission check, an open database — that nobody thought to ask about. This guide gives you the questions that catch them early, especially when code is written by AI.
Guide 6 of 13 in the technical PM path
Why a PM should care
- Security bugs are product bugs — with the highest cost: lost data, lost trust, legal exposure.
- Many are requirement gaps. "Who is allowed to do this?" is a product question; if nobody answers it, nothing enforces it.
- Customers ask. B2B deals increasingly include security questionnaires.
- AI-generated code makes it easy to ship insecure defaults quickly.
You are not expected to be a security engineer. You are expected to make security part of the definition of done.
1. Secrets must stay secret
API keys, database passwords and tokens give access to paid services and data. The rules:
- Never in frontend code — anything the browser downloads can be read.
- Never committed to Git, even in private repositories (and deleting later does not remove them from history).
- Stored in environment variables or a secrets manager, with the minimum permissions needed.
- Rotated (replaced) immediately if exposed.
2. Authorization on every request
Checking that a user is logged in is not enough; the server must check that they are allowed to access this specific record. The classic failure: changing /invoices/1042 to /invoices/1043 shows another customer's invoice. Hiding buttons in the UI does not count — permissions must be enforced on the server or in database rules. See authentication and authorization for product managers.
3. Never trust input
Anything that comes from users — form fields, URLs, uploaded files, API requests — can be malicious.
- Injection (e.g. SQL injection): input is treated as code by the database. Prevented by parameterised queries and ORMs, which most modern frameworks use by default.
- XSS (cross-site scripting): a user saves text containing a script, and your app shows it to others, running that script in their browser. Prevented by escaping output — frameworks like React do this by default unless developers bypass it.
- File uploads: limit types and sizes, and never execute or serve uploaded files as-is from your main domain.
- Validation: check input on the server, even if the frontend already checks it.
4. Sessions and CSRF
CSRF (cross-site request forgery) tricks a logged-in user's browser into sending a request they did not intend — for example, from a malicious page. Modern defaults (SameSite cookies, token-based APIs, CSRF tokens) handle most cases; the PM question is simply whether sensitive actions (changing email, deleting data, payments) are protected and sometimes require re-confirmation.
5. Rate limiting and abuse
Anything free, public or expensive will be abused: sign-up forms, login, password reset, AI features, email sending. Rate limits (for example, 5 login attempts per minute) and quotas protect both security and your cloud bill.
6. Dependencies
Modern apps use hundreds of open-source packages. Vulnerabilities are found in them regularly. Teams should use automated tools (such as GitHub Dependabot or npm audit) to keep them updated — and think twice before adding a new package for a small feature.
7. Privacy by design
- Collect only the personal data you need, and know where it lives.
- Decide how long you keep it, and how a user can export or delete it.
- Keep production data out of development and testing environments.
- Be careful with what you send to third parties — analytics, error tracking and AI providers included.
The AI-generated code checklist
AI coding agents write working code fast — and commonly make these mistakes:
- calling paid APIs directly from the browser with the key in the code;
- checking login but not ownership of records;
- database rules left open "for testing";
- disabling validation or security checks to make an error go away;
- adding unnecessary or abandoned packages;
- logging sensitive data (tokens, passwords, full request bodies).
After any significant AI-built feature, ask the agent: "Review this change for security issues: secrets, authorization, input validation, injection, XSS, rate limiting and data exposure. List concrete problems with file and line." Then verify the top items yourself.
What engineers may tell you
- "We need to rotate that key." It may have leaked; replace it and update everywhere it is used.
- "That's an IDOR." A user can access another user's data by changing an ID.
- "We should do a threat model." Think systematically about what could go wrong and who might attack it.
- "Pen test findings came back." External testers found vulnerabilities to prioritise.
Questions a good technical PM asks
- What data does this feature touch, and who is allowed to see or change it?
- Where is that permission enforced?
- Are any secrets involved, and where do they live?
- What happens if someone sends 10,000 requests to this endpoint?
- What personal data do we store or send to third parties, and for how long?
- How would we know if this was being abused?
Security in acceptance criteria
Add lines like these to your stories:
- A user can only view and edit tasks in projects they are a member of; a non-member receives 403.
- The provider API key is only used server-side; it is not present in any frontend bundle.
- Password reset is limited to 5 requests per hour per email and per IP.
- Deleting an account removes the user's personal data within 30 days.
Try it yourself
Pick one feature and walk through the list above in 15 minutes with your tech lead. You will almost always find one gap — and fixing it before launch is far cheaper than after.
In the TechPMer course, week 7 covers data security rules and week 9 (“Testing, Debugging & Reviewing AI Code”) includes a security review of your own AI-built project.