C-SWCM cheat sheet

STRIDE maps threats to properties: Spoofing→authentication, Tampering→integrity, Repudiation→non-repudiation, Information disclosure→confidentiality, Denial of service→availability, Elevation of privilege→authorization.

DREAD scores risk as (Damage + Reproducibility + Exploitability + Affected users + Discoverability)/5; higher total means higher priority, though the model is subjective.

A trust boundary exists wherever data crosses between components of different privilege or ownership; every crossing point is a candidate for validation and threat enumeration.

Data flow diagrams use four element types: external entity, process, data store, and data flow; threat enumeration is applied per element using STRIDE-relevant categories.

Attack trees decompose a goal (root) into sub-goals joined by AND/OR nodes; the root is only achievable if AND children all succeed or an OR child succeeds.

Defense in depth layers independent controls so a single failure does not yield compromise; controls should not share the same failure mode (e.g., same credential store).

Least privilege and fail-safe defaults (deny unless explicitly permitted) are foundational design principles; fail-open behavior during errors is a design defect.

Threat modeling is iterative and belongs in design review, not only pre-release; re-run when architecture, data flows, or trust boundaries change.

Risk = likelihood × impact; qualitative scales (low/medium/high) are acceptable when calibrated against defined criteria per organization.

NIST SP 800-63B treats SMS and email OTP as restricted authenticators; phishing-resistant options are FIDO2/WebAuthn security keys and passkeys bound to origin.

Password storage must use a memory-hard or adaptive KDF (Argon2id, scrypt, bcrypt, or PBKDF2 with high iterations) plus a unique per-user salt; plain SHA-256 is unsuitable.

Session identifiers must be generated by a CSPRNG with at least 128 bits of entropy, transmitted only over TLS, and marked Secure, HttpOnly, and SameSite.

Session fixation is prevented by issuing a new session ID at authentication and at privilege change; the old identifier must be invalidated server-side.

RBAC grants permissions to roles and roles to users; ABAC evaluates attributes of subject, resource, action, and environment and supports finer-grained policy.

Broken object-level authorization (IDOR) occurs when the server trusts a client-supplied identifier; every access must verify the subject owns or may access the object.

OAuth 2.0 is an authorization framework, not authentication; OpenID Connect adds an ID token (JWT) and UserInfo endpoint for identity.

In OAuth, the authorization code flow with PKCE binds the code to a code_verifier; implicit flow is deprecated because tokens leak via URL fragments.

Multi-factor authentication requires factors from different categories: knowledge (password), possession (token), inherence (biometric); two passwords are single-factor.

SQL injection is prevented primarily by parameterized queries/prepared statements; escaping and blocklists are secondary and error-prone.

Stored procedures are safe only when they do not build dynamic SQL by concatenation; EXEC with string concatenation reintroduces injection.

XSS types: reflected (payload in immediate response), stored (persisted server-side), DOM-based (sink executes tainted source in client JS).

Context-aware output encoding is required per sink: HTML body, HTML attribute, JavaScript, CSS, URL, and SQL each need different encoding.

Content Security Policy mitigates XSS by restricting script sources; nonce- or hash-based CSP is preferred over 'unsafe-inline' allowlists.

Command injection is prevented by avoiding shell invocation and using argument-array APIs (e.g., execve-style) with allowlist validation on inputs.

Input validation should be allowlist-based (define what is permitted) and applied server-side; client-side validation is usability only.

Second-order (persistent) injection occurs when stored data is later used unsafely; validation at input time does not substitute for safe use at sink time.

LDAP, XPath, and NoSQL injection follow the same pattern: untrusted data interpreted as query syntax; use parameterized APIs or typed queries.

AES-GCM provides authenticated encryption (confidentiality + integrity); never reuse a nonce with the same key, and never use ECB mode for structured data.

Encrypt-then-MAC is the safe composition order; MAC-then-encrypt and encrypt-and-MAC expose padding-oracle and forgery risks.

TLS 1.2/1.3 with forward secrecy (ECDHE) is required; disable SSLv3, TLS 1.0/1.1, RC4, 3DES, and export ciphers.

HSTS (Strict-Transport-Security) with includeSubDomains and preload forces HTTPS; it does not protect the first request unless preloaded.

Password hashing differs from encryption: hashes are one-way and salted; encryption is reversible and requires key management.

Key management: use a KMS/HSM, rotate keys, separate keys by purpose, and never commit secrets to source control; secrets belong in a vault.

Digital signatures provide authenticity and integrity, not confidentiality; verify signatures with a trusted public key and check the certificate chain.

Random values for tokens must come from a CSPRNG (e.g., /dev/urandom, crypto.randomBytes); Math.random and time-based seeds are predictable.

Data at rest should be encrypted with envelope encryption: a data key encrypts content, and a master key (in KMS) wraps the data key.

Validate on the server; treat all client input, headers, cookies, and third-party API responses as untrusted.

Avoid dangerous APIs: eval, deserialization of untrusted data, shell execution, and dynamic SQL construction from strings.

Insecure deserialization is mitigated by avoiding native serialization of untrusted data, using allowlists of classes, and integrity checks (HMAC) on serialized blobs.

Error handling must fail closed and avoid leaking stack traces, SQL errors, or internal paths to clients; log details server-side with correlation IDs.

Security headers to set: Content-Security-Policy, X-Content-Type-Options: nosniff, Referrer-Policy, and frame-ancestors (or X-Frame-Options) for clickjacking.

SSRF is mitigated by allowlisting destinations, blocking link-local/metadata addresses (169.254.169.254), and disabling redirects to internal ranges.

File uploads require extension and content-type allowlists, storage outside the web root, randomized filenames, and antivirus scanning.

Race conditions (TOCTOU) are mitigated by atomic operations, database constraints, and locking rather than check-then-act logic.

Microservice architectures require service-to-service authentication (mTLS or signed tokens) and per-service authorization, not implicit trust of the internal network.

Reconnaissance includes passive OSINT and active enumeration; scope and rules of engagement must be defined in writing before testing.

OWASP Top 10 is an awareness document of risk categories, not a checklist; OWASP ASVS and WSTG provide verifiable requirements and test procedures.

CVSS base score combines exploitability and impact metrics; temporal and environmental metrics adjust the base for context.

False positives must be validated manually; automated scanners report potential findings that require reproduction with a proof of concept.

Testing for IDOR requires two accounts at different privilege levels and swapping identifiers to confirm missing authorization checks.

Blind SQLi is detected via time-based or boolean-based inference; out-of-band techniques use DNS or HTTP callbacks.

A penetration test report should include finding, evidence, reproduction steps, impact, CVSS score, and remediation guidance.

Authenticated scanning yields deeper coverage than unauthenticated; session handling and multi-role testing are required for meaningful results.

Retesting after remediation confirms fixes and checks for regressions; a finding is closed only after verification.

Harden web servers by disabling directory listing, removing default pages and sample apps, and running the service as a non-root low-privilege account.

TLS configuration should disable weak protocols and ciphers; OCSP stapling and HSTS improve transport posture.

API security: enforce authentication on every endpoint, rate-limit, validate content types, and use schema validation for request bodies.

Broken object-level authorization and excessive data exposure are top API risks; responses should return only fields the client needs.

Cloud IAM: apply least privilege, avoid wildcard actions/resources, and use roles instead of long-lived access keys.

Instance metadata services (IMDSv2) should require session tokens; SSRF to 169.254.169.254 can steal cloud credentials if IMDSv1 is enabled.

Containers should run as non-root, use read-only root filesystems, drop Linux capabilities, and avoid privileged mode.

Kubernetes: enable RBAC, network policies, Pod Security Standards, and secrets encryption at rest; avoid hostPath mounts and hostNetwork.

Secrets in container images or environment variables are extractable; use a secrets manager with short-lived credentials.

Secure SDLC phases: requirements (security requirements), design (threat modeling), implementation (secure coding), verification (SAST/DAST/SCA), and operations (monitoring).

SAST analyzes source or bytecode without executing; DAST tests a running application from outside; IAST instruments runtime; SCA identifies vulnerable dependencies.

Shift-left means integrating security checks into CI/CD gates so defects are found earlier, when remediation cost is lower.

Risk treatment options: mitigate, transfer (insurance), avoid, or accept; acceptance must be documented with an accountable owner.

Compliance frameworks: PCI DSS for cardholder data, HIPAA for health data, GDPR for EU personal data, SOC 2 for service controls.

OWASP SAMM and BSIMM are maturity models that measure security practices across governance, design, implementation, and verification.

Security requirements should be testable and traceable to design and test cases; 'the app must be secure' is not a verifiable requirement.

Bug bounty and vulnerability disclosure programs provide external reporting channels; a published security.txt defines contact and policy.

Supply chain risk: pin dependency versions, verify signatures, monitor advisories, and generate an SBOM for transparency.

Incident response phases (NIST): preparation; detection and analysis; containment, eradication, and recovery; post-incident activity.

Containment options include isolating hosts, revoking credentials, blocking IPs, and disabling features; preserve evidence before destructive actions.

Logging should capture authentication events, authorization failures, input validation failures, and administrative actions with timestamps and correlation IDs.

SIEM correlates logs across sources; alert tuning reduces false positives and ensures high-signal detections.

Indicators of compromise for web apps include anomalous 4xx/5xx spikes, unusual user agents, and repeated failed logins followed by success.

Forensics requires chain of custody, hashing of evidence, and volatile data capture (memory, connections) before shutdown.

Post-incident review produces root cause, timeline, and corrective actions; lessons learned feed back into the SDLC.

Breach notification timelines are jurisdiction-specific (e.g., GDPR 72 hours to the supervisory authority) and depend on confirmed risk.

Web application firewalls provide virtual patching and detection but are not a substitute for fixing vulnerable code.