Threats, Attacks, Vulnerabilities, and Countermeasures


What’s the difference between software threats, attacks, and vulnerabilities?  While working on Improving Web Application security, we found a lot of confusion, so we came up with a simple way to quickly communicate the terms.

Key Terms

  • Threat – A negative effect or undesired event. A potential occurrence, often best described as an effect that might damage or compromise an asset or objective. It may or may not be malicious in nature.
  • Vulnerability – A weakness in some aspect or feature of a system that makes an exploit possible. Vulnerabilities can exist at the network, host, or application levels and include operational practices.
  • Attack (or exploit) – An action taken that uses one or more vulnerabilities to realize a threat. This could be someone following through on a threat or exploiting a vulnerability.
  • Countermeasure – Addresses a vulnerability to reduce the probability of an attack or the impact of a threat. They do not directly address threats; instead, they address the factors that define the threats. Countermeasures range from improving application design, or improving your code, to improving an operational practice.


You can use threats, attacks, vulnerabilities and countermeasures to organize your security information.  Here’s an example of organizing threats, attacks, vulnerabilities and countermeasures for Input/Data validation:

Threats/Attacks for Input/Data Validation

  • Buffer overflows
  • Cross-site scripting
  • SQL injection
  • Canonicalization attacks
  • Query string manipulation
  • Form field manipulation
  • Cookie manipulation
  • HTTP header manipulation

Vulnerabilities for Input/Data Validation

  • Using non-validated input in the Hypertext Markup Language (HTML) output stream
  • Using non-validated input used to generate SQL queries
  • Relying on client-side validation
  • Using input file names, URLs, or user names for security decisions
  • Using application-only filters for malicious input
  • Looking for known bad patterns of input
  • Trusting data read from databases, file shares, and other network resources
  • Failing to validate input from all sources including cookies, query string parameters, HTTP headers, databases, and network resources

Countermeasures for Input/Data Validation

  • Do not trust input
  • Validate input: length, range, format, and type
  • Constrain, reject, and sanitize input
  • Encode output
Previous articleFirst Post
Next articleSTRIDE Explained


Comments are closed.