Security

Glossary#

• CWE — Common Weakness Enumeration. A catalog of types of flaws (CWE-79 XSS, CWE-89 SQLi, CWE-639 IDOR). Each OWASP category maps to a set of CWEs.
• CVE — Common Vulnerabilities and Exposures. One specific instance of a flaw in a specific product/version (CVE-2021-44228 = Log4Shell). CWE is the class; CVE is the bug.
• CVSS — Common Vulnerability Scoring System. 0–10 severity score from vectors (attack vector, complexity, privileges, user interaction, confidentiality/integrity/availability impact). v3.1 and v4.0 in use. Critical ≥ 9.0, High 7–8.9.
• SAST — Static Application Security Testing. Scans source without running it (Semgrep, CodeQL, SonarQube). Finds patterns; false positives.
• DAST — Dynamic Application Security Testing. Attacks the running app from outside, black-box (OWASP ZAP, Burp Scanner). Finds what's reachable; no code context.
• IAST — Interactive AST. Agent inside the running app watches data flow during tests. Hybrid of SAST+DAST.
• SCA — Software Composition Analysis. Inventories dependencies and matches them against vulnerability databases (npm audit, Snyk, Dependabot, Renovate).
• SBOM — Software Bill of Materials. Machine-readable list of every component in a build (formats: CycloneDX, SPDX). Lets you answer "are we affected?" in minutes.
• Pentest vs bug bounty — Pentest: scoped, time-boxed, contracted engagement with a report and attestation. Bug bounty: continuous, open-ended, pay-per-valid-finding from external researchers under a published policy/scope (HackerOne, Bugcrowd, Intigriti). Pentest proves diligence; bounty finds what pentesters missed.
• Threat model — Structured exercise: what are we building, what can go wrong (STRIDE), what do we do about it, did we do it well enough. Output: data-flow diagram with trust boundaries + ranked threats + mitigations.
• Attack surface — Every point where an untrusted actor can send input or extract data: routes, params, headers, files, queues, admin panels, third-party integrations. Reduce it before defending it.
• Trust boundary — A line in the architecture where the level of trust changes (browser→API, API→DB, service→service, user→admin). Every crossing needs validation and authorization.
• Least privilege — Each identity (user, service, DB role, CI token) gets only the permissions it needs, for only as long as it needs them.
• Defense in depth — Multiple independent layers so one failure isn't a breach: parameterized queries AND input validation AND a low-privilege DB user AND WAF.
• Fail closed — When a security control errors (policy service down, config missing, exception thrown), the default is deny. Fail open = default allow = the A10 anti-pattern.
• Zero trust — No implicit trust from network location. Every request is authenticated, authorized, and encrypted regardless of whether it comes from "inside".
• OWASP ASVS — Application Security Verification Standard. Checklist of ~280 requirements across 3 levels (L1 baseline, L2 most apps, L3 high-value). The "how secure is secure enough" yardstick for audits.
• OWASP Cheat Sheet Series — Concise, per-topic implementation guidance (Authentication, Session Management, XSS Prevention, SQL Injection Prevention, Nodejs Security, …). The thing you cite when asked "how would you fix it."
• Also useful: OWASP Testing Guide (WSTG) — the pentester's methodology; OWASP API Security Top 10 — BOLA, broken auth, unrestricted resource consumption, BFLA, SSRF (API-specific list); MITRE ATT&CK — adversary tactics/techniques, post-exploitation focused.

How to talk about security in an interview (6 lines)#

1. "I think about it as trust boundaries: every place untrusted input crosses into my code is where I validate, authorize, and encode."
2. "Access control is the #1 issue — I enforce authorization per object, server-side, deny by default; the UI hiding a button is not a control."
3. "For data: parameterized queries, output encoding by context, schema validation at the edge, and CSP as the backstop — separate code from data."
4. "For secrets and crypto I don't improvise: argon2/bcrypt/scrypt for passwords, AES-GCM, CSPRNG tokens, constant-time compares, keys from a KMS."
5. "Supply chain and config are where I've seen real incidents: lockfile + npm ci, pinned deps, SCA in CI, no debug flags in prod, headers via helmet."
6. "And I design the failure path: fail closed, timeouts, bounded retries, generic errors to the client, structured logs of auth/authz events wired to alerts."