Threat Modelling (STRIDE)
Identify security requirements before they become vulnerabilities: STRIDE threat modelling (Spoofing impersonating another user; Tampering modifying data; Repudiation denying an action; Information Disclosure unauthorised data access; Denial of Service making system unavailable; Elevation of Privilege gaining unauthorised access levels), data flow diagramming (DFD map all data flows, identify trust boundaries, highlight where sensitive data crosses trust boundary), threat enumeration (for each trust boundary crossing: what threats are possible? probability and impact?), countermeasure mapping (for each threat: what control mitigates it? is it implemented?). STRIDE conducted as collaborative session with development team building shared security understanding.
Injection Prevention
Prevent injection vulnerabilities: SQL injection (Prisma ORM and parameterised queries user input never concatenated into SQL strings; raw SQL uses positional parameters `db.query('SELECT * FROM users WHERE id = $1', [userId])`), NoSQL injection (MongoDB queries constructed from typed objects, not string interpolation; Zod/Joi validation before DB ops), OS command injection (avoid shell execution functions `exec()`, `system()` with user input; use library APIs instead of shell commands), SSTI (use auto-escaping template engines, never pass user input directly to template evaluation).
Authentication & Session Security
Harden authentication implementation: password hashing (bcrypt with work factor 12+ or Argon2id never MD5, SHA-1, or SHA-256 without salt), brute force protection (rate limiting on login endpoints progressive delays, CAPTCHA after N failures, account lockout with unlock mechanism), secure session management (HttpOnly + Secure + SameSite=Strict cookie attributes, cryptographically random session tokens, session rotation on privilege escalation, invalidation on logout), JWT best practices (RS256 or HS256 with strong secret, short access token TTL 15 minutes, refresh token rotation, no sensitive data in JWT payload JWTs are base64 encoded, not encrypted), MFA implementation (TOTP Time-based One-Time Password RFC 6238, FIDO2/WebAuthn for phishing-resistant MFA).
Content Security Policy (CSP)
XSS mitigation through HTTP response headers: CSP design (strict-dynamic + nonce-based CSP most effective XSS mitigation, avoids unsafe-inline which undermines CSP), nonce generation (per-request random nonce injected into CSP header and all inline scripts prevents attacker-injected scripts from executing), CSP reporting (report-uri or report-to directive collect CSP violation reports to identify both attacks and legitimate scripts blocked), Trusted Types (emerging standard enforces type safety for DOM manipulation prevents DOM XSS by requiring all HTML assignment to use Trusted Type), incremental CSP deployment (use Content-Security-Policy-Report-Only header first to collect violations without blocking tune policy before switching to enforcement).
Security Remediation Engineering
Fix the specific vulnerabilities identified in a security audit or pen test: vulnerability triage (review audit findings with engineering team, clarify reproduction steps, assess fix complexity), fix implementation (ClickMasters engineers implement the fixes not advisory-only), verification (reproduce vulnerability before fixing, confirm not reproducible after fixing), regression prevention (add security test for each fixed vulnerability the test fails if vulnerability is reintroduced), re-test (for pen test findings coordinate re-testing by original provider or conduct application-level re-testing internally). Deliverable: pull requests for all fixes, verified remediation, closing report for each finding.
