C-SWCM key terms

A structured method of identifying assets, entry points, attackers, and likely abuse paths in a system before code is written, so that controls can be designed in rather than added after a breach.

A mnemonic grouping of six threat categories: spoofing identity, tampering with data, repudiation, information disclosure, denial of service, and elevation of privilege. Teams use it to prompt systematic threat brainstorming per component.

The total set of points where an outsider can interact with or influence an application: URLs, parameters, APIs, file uploads, ports, third-party integrations, and credentials. Reducing it shrinks the number of places needing defense.

A diagram showing how data moves between users, processes, stores, and trust boundaries. In threat modeling it reveals where data crosses from a less trusted zone into a more trusted one and therefore where controls belong.

Any line where data or control passes between components with different privilege or assurance levels, such as browser to server or app tier to database. Every crossing must validate and authenticate the incoming data.

Layering independent controls so that failure of one does not expose the system. For example, input validation plus parameterized queries plus least-privilege database accounts all must fail before SQL injection becomes exploitable.

An attack outcome in which a user gains rights beyond those granted, such as a standard account reaching administrative functions. It often results from missing authorization checks or insecure direct object references.

Authentication that requires two or more independent evidence types, such as a password plus a hardware token or push approval. Independence matters: two passwords are not two factors.

The mechanism that keeps a user recognized across stateless HTTP requests using a token or cookie. Secure design requires unpredictable identifiers, secure cookie attributes, idle and absolute timeouts, and invalidation at logout.

An attack where the attacker plants a known session identifier on the victim, who then authenticates with it, letting the attacker reuse the same identifier. Rotating the session ID at login defeats it.

Failure to enforce that each authenticated user may perform only permitted actions on permitted objects. It includes missing function-level checks and accessing other users' records by changing an identifier.

A flaw where an application exposes an internal identifier such as a record number and uses it without verifying the requester owns that record, so changing the number exposes other users' data.

Automated login attempts using username and password pairs leaked from other breaches, exploiting password reuse. Rate limiting, breached-password checks, and multi-factor authentication reduce its success.

Leaking whether an account exists through differing error messages, response times, or status codes. Attackers use it to build target lists, so login and reset flows should respond uniformly.

Checking that incoming data matches expected type, length, format, and range before use. It is best done as allowlisting on the server, since client-side checks can be bypassed by anyone controlling the request.

Inserting SQL syntax through user-supplied data so that the database interprets it as code. Parameterized queries, which separate code from data, are the primary and most reliable defense.

A query written with placeholders whose values are bound separately by the database driver, so input can never alter query structure. Also called a prepared statement; it is the definitive fix for SQL injection.

Injecting script into pages other users view, so the code runs in their browser under the site's origin and can steal sessions or act as the user. Context-aware output encoding and a strict content security policy mitigate it.

Transforming data at the point of rendering so browsers treat it as text, not markup or script. The correct encoding depends on context: HTML body, attribute, URL, JavaScript, or CSS.

An HTTP response header that tells the browser which script, style, and other resource sources are permitted. A well-tuned policy blocks inline script and limits the impact of any injection that slips through.

Passing untrusted data into an operating system command so that shell metacharacters execute extra commands. Avoiding shell invocation and passing arguments as an array to the process API removes the risk.

Tricking a logged-in user's browser into sending a state-changing request to a site that trusts the user's cookies. Anti-CSRF tokens and SameSite cookie attributes are standard defenses.

A cookie attribute controlling whether the browser sends the cookie on cross-site requests. Lax or Strict settings block many cross-site request forgery attempts, though they are not a complete substitute for tokens.

Protecting stored data, including databases, backups, and disks, with encryption so that stolen media or snapshots are unreadable without keys. Key custody and rotation determine how much protection it actually provides.

Protecting data moving between systems with protocols such as TLS, preventing eavesdropping and tampering on the network. Certificate validation and modern protocol versions are essential to its value.

The lifecycle practices for cryptographic keys: generation with sufficient randomness, secure storage, controlled access, rotation, and destruction. Weak key handling undermines even strong algorithms.

Storing a slow, salted, one-way digest of each password instead of the password itself, using an algorithm designed for the purpose such as bcrypt, scrypt, or Argon2. Salting prevents precomputed cracking across users.

Flags that restrict cookie exposure: Secure sends it only over TLS, HttpOnly hides it from scripts, and SameSite limits cross-site sending. Together they reduce session theft and request forgery.

Granting each user, service, and process only the permissions needed for its task, for the shortest practical time. It limits blast radius when an account or component is compromised.

Designing error paths so that a failure denies access rather than granting it, and so that error output reveals no internals. A crashed authorization check must not default to allowing the request.

Insecure defaults and settings such as debug modes left on, default credentials, verbose errors, open cloud storage, or unneeded services. Hardened baselines and configuration review prevent it.

An HTTP response header that instructs the browser to apply protections, such as HSTS, X-Content-Type-Options, frame options, and content security policy. Missing headers widen exploitation of other flaws.

A credential such as a signed JWT or opaque bearer token presented with API calls to prove identity. Tokens must be scoped narrowly, expire, be validated fully, and never be placed in URLs where they get logged.

Automatically inspecting container images for known vulnerable packages, embedded secrets, and misconfigurations before deployment. Scanning in the build pipeline catches issues earlier and cheaper than runtime detection.

Authorized, scoped simulated attack against a running application to find exploitable weaknesses and demonstrate business impact. It complements, but does not replace, code review and threat modeling.

Examining source or bytecode without executing it to find patterns such as tainted data reaching dangerous sinks. It scales well across a codebase but produces false positives that require triage.

Testing a running application, often with instrumented scanning or fuzzing, to observe real behavior and runtime flaws. It finds issues static tools miss but covers only the paths actually exercised.

Embedding security activities such as requirements, threat modeling, code review, and testing into each phase of software development rather than bolting them on before release. It lowers the cost of fixing defects.

Identifying third-party libraries and their versions, then matching them against known vulnerability databases and license rules. It addresses risk inherited from dependencies a team did not write.

A formal decision to tolerate an identified risk, with documented rationale, owner, and review date. It is legitimate only when informed and recorded, not when a finding is quietly ignored.

Prioritizing findings by exploitability, exposure, and business impact so remediation effort goes to the most dangerous issues first. Severity scores inform but do not replace context about the affected system.

Recording authentication, authorization, and high-risk actions in tamper-resistant logs and alerting on suspicious patterns. Without it, intrusions go unnoticed and incident timelines cannot be reconstructed.

The organized process of preparing for, detecting, containing, eradicating, and recovering from a security incident, followed by lessons learned. Clear roles and pre-approved playbooks shorten containment time.

Preserving and analyzing evidence such as logs, memory, and disk images in a way that maintains integrity for investigation or legal use. Chain of custody and hashing of collected artifacts support that goal.