Appsec

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 Vulnerabilityflaw in code / confige.g. CWE-89, missing bounds checkExploitpayload / PoC / techniquetriggers the crack aboveResultCompromise(RCE, data leak,privilege escalation) 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 ...

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 CSRFXSSVictim Browseractive session cookieAttacker Siteforged auto-submit formTarget Servere.g. bank / app backendAction Executedusing victim's cookievisits pagecookie auto-attachedno injected codeVulnerable Siterenders unsanitized inputInjected <script>runs in page's own originVictim Browserexecutes attacker JSAttacker Serverreceives stolen datainput reflected as codefull DOM accesscookie exfiltrated 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 ...

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 SASTsource code, no executionfunction login(u,p) { const q = "SELECT..+p"; db.exec(q);}reads code, flags line 128e.g. unsanitized SQL concatDASTrunning app, black-boxLive App/login endpointPOST u=' OR 1=1--sends live requests, observes responsee.g. auth bypass returned 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 ...