Appsec on IT Comparison

Vulnerability vs Exploit: Weakness or Weapon

Mon, 03 Aug 2026 04:32:55 +0900

Overview

A vulnerability is a flaw in software, hardware, or configuration that could theoretically be abused, while an exploit is the actual attack code or technique that triggers that flaw to produce a specific outcome. The distinction matters because a system can carry thousands of vulnerabilities with no working exploit, while a single reliable exploit turns a theoretical risk into an active breach.

Comparison Diagram

Comparison Table

Aspect	Vulnerability	Exploit
What it is	A latent flaw or weakness in design, code, or configuration	A concrete piece of code, script, or technique that abuses a flaw
Discovery method	Found via code review, fuzzing, static/dynamic analysis, or audits	Built by weaponizing a known vulnerability into a working trigger
Prerequisite	Requires nothing but the flaw’s existence in the system	Requires an identified, reachable vulnerability to target
Lifecycle stage	Introduced at design/coding time, persists until patched	Created after a vulnerability is discovered, often much later
Public tracking	Cataloged with a CVE identifier and CWE weakness class	Published as PoC code, Metasploit modules, or Exploit-DB entries
Detection in the wild	Identified by vulnerability scanners and SAST/DAST tools	Identified by IDS/IPS signatures, EDR behavior, or WAF rules
Mitigation	Fixed by patching, input validation, or config hardening	Blocked by runtime protections, signatures, or exploit mitigations (ASLR, DEP)
Risk measurement	Scored theoretically via CVSS base/temporal metrics	Measured by real-world impact and inclusion in CISA’s KEV list

Key Differences

A vulnerability is a static flaw; an exploit is the active trigger that abuses it
Vulnerabilities can sit unexploited for years; exploits require a working, reachable target
Vulnerabilities are tracked by CVE identifiers; exploits circulate as PoC code or modules
Patching closes the vulnerability; runtime defenses block the exploit itself
CVSS scores the theoretical risk of a vulnerability; KEV listing confirms an exploit is used in the wild

When to Use Each

Vulnerability

CSRF vs XSS: Forged Requests or Injected Scripts

Mon, 03 Aug 2026 04:27:16 +0900

Overview

CSRF and XSS are both web attacks that abuse a victim’s trusted relationship with a site, but they exploit opposite ends of that trust. CSRF forges a request using the victim’s own session cookie without ever running attacker code in the browser, while XSS smuggles injected script into a vulnerable page so it executes directly inside the victim’s browser.

Comparison Diagram

Comparison Table

Aspect	CSRF	XSS
Attack vector	Forged cross-site request, e.g. an auto-submitting form or image tag on the attacker’s page that targets the victim site	Malicious script injected into a vulnerable page’s HTML or JS output, often via unsanitized user input
Trust exploited	Server’s trust that any request carrying a valid session cookie came from the legitimate user	Browser’s trust that all script served from the site’s origin is safe to execute
Where the payload runs	Nowhere on the victim’s browser beyond a normal HTTP request; the ‘payload’ is the request itself	Attacker’s JavaScript executes directly inside the victim’s browser, in the vulnerable site’s own origin
Prerequisite for success	Victim must have an active authenticated session with the target site when the forged request fires	Vulnerable site must reflect, store, or render attacker-controlled input without proper sanitization or escaping
Attacker capability	Limited to whatever action the victim’s existing session is authorized to perform, like a transfer or settings change	Broad: read cookies and localStorage, capture input, deface the page, or pivot into session hijacking
Primary defense	Anti-CSRF tokens, SameSite cookies, and origin or referer checks	Output encoding, Content Security Policy, and strict input sanitization
Typical impact scope	A single forged action, bounded by what the target endpoint allows	Potential full account takeover or persistent compromise if the injection is stored

Key Differences

CSRF forges a request using the victim’s existing session cookie; XSS injects attacker script that runs inside the victim’s browser.
CSRF requires no code injection into the target site, while XSS depends entirely on unsanitized input reaching the page.
XSS can read and exfiltrate data straight from the DOM, whereas CSRF is limited to blind requests with no response visibility.
SameSite cookies mitigate CSRF but do nothing against XSS, which is stopped primarily by CSP and output encoding.

When to Use Each

CSRF

SAST vs DAST: Static vs Dynamic Application Security Testing

Mon, 03 Aug 2026 04:19:31 +0900

Overview

SAST scans an application’s source code at rest to catch insecure patterns before the app ever runs, while DAST attacks a running application from the outside to find exploitable flaws in its live behavior. Teams use both because each catches vulnerability classes the other structurally cannot see.

Comparison Diagram

Comparison Table

Aspect	SAST	DAST
What it examines	Source code, bytecode, or binaries at rest	A running, deployed application from outside
Access level	White-box — full visibility into code internals	Black-box — only sees inputs and outputs like an attacker
When in SDLC	Early, during coding and in CI on every commit	Later, once a build is deployed to a test or staging environment
Environment needed	None — analyzes files directly, no app needs to run	A live, reachable instance of the application
Vulnerability classes found	Insecure code patterns: SQL string building, hardcoded secrets, unsafe deserialization	Exploitable runtime behavior: auth bypass, injection responses, misconfigured headers
Language/stack dependency	Tied to the language and framework being parsed	Language-agnostic — probes over HTTP/HTTPS regardless of stack
False positive tendency	Higher — flags patterns that may not be reachable or exploitable	Lower — findings are confirmed by actual exploit attempts
Remediation output	Exact file and line number to fix	Vulnerable URL, parameter, and request/response evidence

Key Differences

SAST inspects source code without running it; DAST attacks a live instance without seeing its internals
SAST fits early into CI pipelines per-commit; DAST needs a deployed build to test against
SAST pinpoints the exact line number; DAST reports the vulnerable endpoint and payload
SAST is prone to false positives from unreachable code paths; DAST confirms via actual exploitation
SAST misses runtime configuration flaws that DAST catches, like missing security headers or session issues

When to Use Each

SAST