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 A digital signature is a cryptographic value that proves a specific piece of data is authentic and unaltered, generated by encrypting a hash with a private key. A digital certificate is a CA-issued document that binds a public key to an identity, giving others a trusted way to know whose key they’re using. Confusing the two leads to designs that either can’t verify who signed something or can’t verify what was actually signed. ...

Overview A VPN creates an encrypted tunnel for all of a device’s network traffic through a remote server, while a proxy forwards traffic from a single app or protocol through an intermediary server, typically without encryption. The distinction matters because it determines what’s protected, how much overhead is added, and what happens when the connection fails. Comparison Diagram VPNProxyDevice (OS)all apps & trafficencrypted tunnelVPN ServerInternetEncrypts & routes ALL device trafficBrowserapp trafficProxy ServerOther Appsbypasses proxy (direct, unencrypted)InternetRoutes only configured app/protocol traffic Comparison Table Aspect VPN Proxy Scope of traffic routed All network traffic from the device (OS-level) Traffic from a specific app or protocol the client is configured to use Where it’s configured System network settings / dedicated client that creates a virtual interface Individual app settings (browser, OS network stack per-app, or system-wide proxy field) Encryption Encrypts traffic between device and VPN server by default No encryption by default; only as strong as the underlying protocol (e.g. HTTPS) Authentication to server Client authenticates with certificates/credentials to establish the tunnel Often none, or simple username/password at the app layer Visibility to local network/ISP ISP and local network see only encrypted tunnel traffic to one endpoint ISP sees the proxy connection plus any traffic from unproxied apps Performance overhead Higher — encryption and full traffic redirection add latency Lower — only proxied traffic is redirected, often with caching Typical use case Secure remote access to a private network, or system-wide privacy on untrusted Wi-Fi Per-app geo-bypass, content filtering, or caching for a single protocol Behavior on failure Well-configured clients include a kill switch that blocks all traffic if the tunnel drops Only the proxied app’s connection fails; other traffic is unaffected Key Differences A VPN operates at the OS network layer, capturing all traffic, while a proxy operates at the application layer for one app or protocol VPN traffic is encrypted by default; proxy traffic is unencrypted unless the underlying protocol adds it VPNs require dedicated client software creating a virtual interface; proxies need only an IP:port entry in an app’s settings A VPN’s kill switch can block all traffic on disconnect; a proxy failure only drops that single app’s connection When to Use Each VPN ...

Overview Malware is the umbrella term for any software designed to damage, disrupt, spy on, or gain unauthorized access to a system — it covers viruses, worms, trojans, spyware, and more. Ransomware is one specific, financially-motivated subtype that encrypts a victim’s files and demands payment for the decryption key. The distinction matters because generic malware defenses don’t always address ransomware’s unique extortion mechanics and recovery challenges. Comparison Diagram Malwareumbrella term for malicious softwareVirusWormTrojanSpywareRansomwareencrypts + extortsfile.doc→file.doc.enc→$ransomnoteransomware's distinguishing payload Comparison Table Aspect Malware Ransomware Scope Broad umbrella category encompassing all malicious software types One specific subtype of malware within that broader category Infection vector Varies widely: email attachments, drive-by downloads, USB, exploited software Same vectors as malware generally, often phishing or exploited RDP/VPN access On-system behavior Ranges from silent data theft to file corruption to self-replication Encrypts (or steals and threatens to leak) files, locking the victim out of their own data Primary objective Varies: espionage, disruption, botnet recruitment, ad fraud, data theft Direct financial extortion via ransom payment Visibility to victim Often designed to stay hidden and undetected for as long as possible Deliberately announces itself with a ransom note and payment deadline Impact scope Can range from minor annoyance to total system compromise Immediate and severe: data becomes inaccessible and operations halt Detection approach Signature and behavior-based antivirus, EDR, network monitoring Same tools plus backup-integrity monitoring and anomalous encryption-pattern detection Remediation Remove infection, patch the vulnerability, restore from a clean state Restore from offline backups or pay the ransom, which is not guaranteed to work Key Differences Malware is the category; ransomware is one subtype within it. Ransomware’s goal is explicit extortion, while other malware often aims for stealthy long-term access. Ransomware deliberately reveals itself via a ransom note, whereas most malware tries to stay hidden. Recovery from ransomware hinges on backups, since decryption without the attacker’s key is often infeasible. When to Use Each Malware ...

Overview Phishing and spear phishing are both social-engineering attacks that trick victims into revealing credentials or installing malware, but they differ in scope and craftsmanship. Phishing casts a wide net using generic, templated lures sent to as many people as possible, while spear phishing is a researched, personalized attack aimed at one specific person or organization. Comparison Diagram Phishing Spear Phishing Atk Attacker Generic template Mass, unknown recipients Atk Attacker Researches target (OSINT) Specific, known individual Comparison Table Aspect Phishing Spear Phishing Target selection Random, mass audience with no vetting Specific individual or organization chosen in advance Reconnaissance effort None; same message sent to everyone Significant OSINT on the target’s role, contacts, and habits Message content Generic, templated (fake bank alert, prize notice) Personalized, referencing real names, projects, or events Sender impersonation Generic brand or authority (bank, IT helpdesk) A specific known contact (manager, vendor, colleague) Delivery volume Thousands to millions of identical emails One or a handful of tailored emails Detection difficulty Often caught by spam filters and obvious red flags Bypasses filters more easily; looks legitimate to the recipient Per-attempt success rate Low click-through rate, offset by sheer volume Much higher, since the message exploits real trust and context Typical impact Scattered credential theft across many accounts High-value breach: wire fraud, data exfiltration, network access Key Differences Spear phishing depends on reconnaissance, phishing needs none Phishing scales through volume, spear phishing scales through credibility Spear phishing messages are personalized to the recipient, phishing uses generic templates Spear phishing has a far higher success rate per message sent Phishing is filtered out more easily; spear phishing often evades automated detection When to Use Each Phishing ...

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 A firewall and a web application firewall (WAF) both filter traffic, but they operate at different layers of the stack. A firewall makes allow/deny decisions based on IP and port, while a WAF inspects the actual HTTP payload of requests to catch application-layer attacks like SQL injection and XSS. Most production environments deploy both, since neither can see what the other is built to catch. Comparison Diagram FirewallWAFRaw network trafficTCP SYN, dst port 22FirewallL3/L4: IP, port, protocolAllow 443Block 22Cannot see inside theHTTP request bodyHTTP requestGET /login?id=1' OR '1'='1WAFL7: URL, headers, bodyAllow normalBlock SQLiDecrypts TLS to inspectthe request payloadLayered defense: firewall blocks unauthorized access, WAF blocks malicious payloads Comparison Table Aspect Firewall WAF OSI layer inspected Network/transport (L3/L4) Application (L7) Traffic filtered All IP traffic, any protocol or port HTTP/HTTPS requests only Inspection criteria Source/destination IP, port, protocol, connection state URL, headers, cookies, and request body content Rule basis Static allow/deny rules and ACLs Signature and behavioral rules for known attack patterns Typical deployment point Network perimeter or between internal subnets In front of or alongside web servers/load balancers Attacks stopped Port scans, unauthorized network access, network-layer floods SQL injection, XSS, CSRF, other OWASP Top 10 exploits Encrypted traffic handling Sees only packet headers, not TLS-encrypted payload Typically terminates TLS to inspect decrypted HTTP content Maintenance cadence Relatively static rule sets, infrequent changes Frequent signature updates as new exploits are discovered Key Differences A firewall filters at the network layer using IP and port, while a WAF filters at the application layer using HTTP content. Firewalls control which connections are permitted; WAFs inspect the payload within connections already allowed through. A WAF typically must decrypt TLS to read requests, whereas a firewall generally cannot see inside encrypted traffic. The two are complementary controls, not substitutes — each blocks a different class of attack the other misses. When to Use Each Firewall ...

Overview JWT and session-based authentication both prove who a user is on every request, but they disagree about where that proof lives. A JWT is a signed, self-contained token the client carries and the server checks locally, while session-based auth hands out a small ID that maps to state the server stores and looks up on every call. That single difference in where state lives cascades into how each approach scales, revokes access, and fits different architectures. ...

Overview OAuth and SAML both let one system vouch for a user to another, but they solve different problems: OAuth is an authorization framework built to grant apps limited access to APIs, while SAML is an XML-based standard built for enterprise single sign-on. Picking the wrong one means using a token-delegation protocol for an identity-federation problem, or vice versa. Comparison Diagram OAuthdelegated authorizationSAMLfederated authenticationClient AppAuthorizationServerAccess Token{ JSON }Resource APIService ProviderIdentity ProviderSAML Assertion<XML>SP Session Comparison Table Aspect OAuth SAML Primary purpose Authorization - grants an app limited, scoped access to resources Authentication - proves a user’s identity for single sign-on Assertion/token format JSON, most commonly a JWT access token XML, a digitally signed SAML assertion Flow initiation Client app redirects the user to an authorization server to request consent Service provider redirects the user to an identity provider to authenticate Credential delivery Access token returned via redirect or back-channel to the client Signed assertion POSTed back to the service provider’s endpoint Transport mechanism REST/HTTP calls carrying a bearer token in the Authorization header HTTP redirect and POST bindings, historically also SOAP Session establishment Client presents the token on each API call to prove access rights Service provider validates the assertion once and creates a local session Lifetime and renewal Short-lived access tokens paired with long-lived refresh tokens Assertions tied to the SSO session with no built-in refresh mechanism Typical ecosystem Mobile apps, SPAs, and third-party API integrations (Google, GitHub) Enterprise SSO into web apps via IdPs like Okta, ADFS, or Azure AD Key Differences OAuth is fundamentally an authorization framework, not an identity protocol, though OpenID Connect layers authentication on top of it. SAML assertions are XML-based and signed, while OAuth tokens are typically JSON, often as a JWT. SAML is built around browser redirects and POST bindings for SSO, while OAuth is built around bearer tokens for API calls. OAuth supports refresh tokens for renewing access; SAML assertions have no native renewal and rely on re-authentication. When to Use Each OAuth ...

Overview Perimeter Security protects a network by treating everything inside a defined boundary as trusted, while Zero Trust assumes no user or device is trusted and requires continuous verification for every request. The distinction matters because cloud adoption, remote work, and lateral-movement attacks have made a hardened network edge insufficient as the sole line of defense. Comparison Diagram Perimeter SecurityTrust based on network locationUserTrusted zone (flat network)FirewallApp ServerDatabaseFile ShareZero TrustVerify every request, every timeUserVerify IdentityApp ServerDatabaseFile ShareMicro-segmented (no lateral trust) Comparison Table Aspect Perimeter Security Zero Trust Core trust model Trust is granted based on network location; inside the boundary is assumed safe No implicit trust; identity and context are verified for every request Entry authentication Checked once at the network edge via firewall or VPN gateway Checked continuously, regardless of where the request originates Internal network structure Largely flat trusted zone once past the boundary Micro-segmented, with access scoped to individual resources Lateral movement after compromise High risk — a foothold on one host can reach many internal systems Low risk — each hop requires separate re-authorization Remote and cloud access Extends the perimeter to remote users via VPN tunnels Grants access by identity, independent of network location Breach containment A single perimeter breach can expose the entire internal network Blast radius limited to the specific resource and session compromised Policy enforcement point Centralized at the network edge (firewall, VPN gateway) Distributed per resource via a policy engine on each request Operational complexity Lower upfront complexity with coarse-grained rules Higher upfront complexity requiring fine-grained, continuously managed policies Key Differences Perimeter Security grants broad access once a device is inside the network boundary; Zero Trust re-authenticates every request. Zero Trust relies on micro-segmentation to isolate resources, whereas Perimeter Security typically has one flat trusted zone. Remote workers under Perimeter Security must tunnel in via VPN; Zero Trust grants access based on identity regardless of location. A breach inside a perimeter can move laterally with little friction; Zero Trust limits blast radius through continuous policy enforcement. Perimeter Security is simpler to deploy initially; Zero Trust requires ongoing identity and context evaluation infrastructure. When to Use Each Perimeter Security ...