Harvard CS50's Intro to Cybersecurity

TLDR

• Security is relative, not absolute — the goal is raising attacker cost until exploitation is economically or computationally impractical.
• Every isolated layer (passwords, hashing, encryption, input validation) can be defeated; defense-in-depth across all five domains is the only durable posture.
• Passkeys, prepared statements, CSRF tokens, and DoH represent the current frontier; developers must build these properties in from the start, not bolt them on.

Caveman

Make attacks too costly; layer defenses; validate all inputs.

ELI5

Security means making it harder for bad actors to get in than it is worth their time. Passwords, encryption, and validation rules are all just ways to raise the price of breaking in. When developers build software, they have to check every door themselves — no single lock keeps everyone out.

Course Map

Module	One-line takeaway	¶start
Securing Accounts	Long unique passwords + authenticator-app 2FA eliminate most opportunistic account takeovers	¶0:00
Password Managers, SSO, and Server-Side Password Hashing	Delegate auth to verified providers; hash + salt every password before storage	¶56:52
Cryptography: Symmetric & Asymmetric Encryption, Digital Signatures, and Passkeys	Asymmetric key pairs solve the shared-secret bootstrapping deadlock and power passkeys	¶1:53:58
Securing Systems: Encryption, HTTPS, and Network Security	Full-disk encryption + HTTPS + HSTS close the most common network and physical exposure windows	¶2:53:48
Systems Security and Securing Software	Firewalls, SSH, and automatic updates minimize attack surface across the full stack	¶3:52:29
Web Application Attacks: XSS, SQL Injection, CSRF, and Input Validation	Escape output, use prepared statements, and treat server-side validation as the only authoritative check	¶4:49:14
CSRF Defenses, Buffer Overflows, Software Security, and Privacy Preservation	CSRF tokens + signed packages + CVE tracking complete the application security layer	¶5:48:15
Web Privacy: Tracking Technologies and Anonymization Tools	Cookies, fingerprinting, and DNS leaks enable tracking even through VPNs; DoH and browser choice limit exposure	¶6:44:51
Privacy Controls and Course Conclusion	Restrict app permissions deliberately; first-principles reasoning transfers directly to new threats	¶7:41:29

Trunk → Branches

Trunk: Security is the practice of raising attacker cost across every layer until exploitation becomes economically or computationally impractical.

Branches:

1. Credentials — long unique passwords + authenticator-app 2FA + password manager close the majority of account-takeover vectors
   • SMS OTP is weaker than authenticator apps because SIM-swapping redirects codes to the adversary’s device before they reach the user [¶44:47]
2. Storage — hash + salt every password server-side using an established library; a site that emails you your plaintext is fully exposed
   • Use SHA-2/SHA-3 family via a vetted library; never implement your own hash or salt logic [¶1:42:00]
3. Cryptography — asymmetric key pairs solve the shared-secret bootstrapping problem; passkeys (WebAuthn) extend this to replace passwords site-by-site
   • Diffie-Hellman lets two parties derive a shared secret without the secret ever crossing the network intact [¶2:28:55]
4. Transport and storage at rest — HTTPS + HSTS + full disk encryption close packet-sniffing and physical-access vectors
   • Emptying the trash does not delete data; enable FileVault/BitLocker from first use before firmware wear-leveling makes later overwrites impossible [¶3:06:26]
5. Application input — escape all HTML output, use prepared statements for SQL, add CSP headers and CSRF tokens to every sensitive form
   • Client-side validation (HTML attributes, JS checks) is cosmetic and trivially bypassed; the server is always the authoritative validator [¶5:36:22]
6. Systems — firewalls whitelist only necessary ports; antivirus + auto-updates patch known threats; zero-day lag makes layered defense mandatory over any single solution
7. Privacy — third-party cookies, unencrypted DNS queries, and browser fingerprinting enable tracking even through VPNs; DoH + HTTPS + deliberate browser choice limit exposure

Key Patterns

Pattern: Raising attacker cost works because adversaries optimize for ROI — a single strong barrier (long password, 2FA, rate limiting) is often enough to redirect them to softer targets. Transfers to any security design decision where “good enough” defense shifts attacker attention elsewhere.

Pattern: Trust boundaries must be enforced at the layer that controls data — client-side controls (HTML attributes, JavaScript validation) are trivially removed with browser developer tools; the server or database must always be the authoritative validator. Transfers to every API endpoint, HTML form, or user-input surface.

Pattern: Cryptographic separation of public and private keys solves the bootstrapping problem once and applies uniformly — SSO tokens, passkeys, TLS handshakes, and digital signatures all rely on the same asymmetric primitive. Transfers whenever you need to prove identity or authenticity without sharing a secret in advance.

Stress Test

Dimension	Detail
Hidden assumption	Users will tolerate the friction of password managers, 2FA enrollment, and HTTPS enforcement — real-world adoption of these measures lags significantly behind the security ideal
Best counterargument	Defense-in-depth creates its own concentration risk: a compromised password manager exposes all credentials at once; a misconfigured CSRF token still leaves a false sense of security
Fails when	Adversaries operate at the social layer — phishing, SIM-swap, insider threats — bypassing all technical controls regardless of cryptographic strength
Fact vs. opinion	The framing of passkeys as an imminent near-universal password replacement is more product-roadmap aspiration than confirmed near-term reality for most services and users
Vendor bias	Produced under [[freeCodeCamp.org]] (grant/partner-funded model); tool examples favor Google and Apple incumbents (Google Password Manager, iCloud Keychain, Google Authenticator). Treat specific product recommendations as illustrative, not prescriptive — vendor-specific tool adoption should be evaluated against organizational context before adoption

In Practice

• Use an authenticator app (not SMS) for 2FA — SIM-swap attacks redirect OTP codes to an adversary’s device before they reach the legitimate user [¶44:47]
• Enable full disk encryption at initial device setup: FileVault on Mac, BitLocker on Windows — firmware wear-leveling on modern SSDs may block later overwrites of degraded sectors [¶3:06:26]
• Replace string-interpolated SQL with prepared statements using ? placeholders; escape five HTML metacharacters (< > & " ') in all user-supplied output before rendering [¶5:25:43]
• Add Content-Security-Policy: script-src 'self' as an HTTP response header and embed a server-generated hidden CSRF token in every sensitive form — blocks inline XSS and cross-site forgery in a single pass [¶5:02:40]
• Install all third-party libraries exclusively through trusted package managers (pip, npm, gem, apt) which enforce digital-signature verification before installation [¶6:19:56]
• Enable DNS over HTTPS (DoH) in OS or browser network settings and disable third-party cookies to prevent ISP domain-lookup surveillance and cross-site behavioral tracking [¶7:29:58]