AVA: Audit Web Applications at Indeed

Ideas you will meet

Distributed Systems

Consensus, time, failure and the fundamentals of scale-out.

Web Security

OWASP risks, XSS, CSRF, CORS and secure design.

What we already know about this

Our own lessons on these ideas. Read them here before you start, so it makes sense.

• Networking and Web Security Deep Dive · 13 minJWT, cookies, CORS and security headersTokens and the browser's rules: what is inside a JWT, where to store tokens, what CORS really controls and the headers worth sending.Read hereClose

  Cookies and sessions, quickly

  A session keeps a user logged in. The usual approach: after login the server creates a random session id, stores session data server-side, and sends the id in a cookie. (Passwords and sessions are detailed in their own lesson.) Good cookie flags:

  Flag	Effect
  HttpOnly	JavaScript cannot read it, limiting theft through XSS
  Secure	Sent only over HTTPS
  SameSite=Lax/Strict	Limits cross-site sending, reducing CSRF
  Path, Domain	Limit where it is sent
  Max-Age / Expires	Lifetime; keep session cookies short-lived with renewal

  JSON Web Tokens (JWT)

  A JWT is a compact, signed token with three dot-separated, base64url parts: header (algorithm), payload (claims) and signature.

  100%

  Figure SDA-NSD-04-1 · Anatomy and checking of a JWT · © forcsguy.com

  Why use them: the API can verify a token without a database lookup, which suits services and mobile apps. The cost: a stateless token is hard to revoke before it expires.

  Good practice

  • Keep access tokens short-lived (minutes) and use refresh tokens (stored carefully, rotated, revocable) to get new ones.
  • Always verify signature, exp, iss (issuer) and aud (audience); pin the algorithm.
  • A JWT is signed, not encrypted: do not put sensitive data in it (use JWE if you must encrypt).
  • Where to store in a browser: HttpOnly cookies resist XSS theft but need CSRF protection; localStorage is readable by any script, so an XSS leaks the token. There is no perfect answer: choose with your threat model, and prevent XSS first.
  • For simple server-rendered apps, server-side sessions are often simpler and easier to revoke than JWTs. (Federated login with OAuth and OpenID Connect is in the SSO lesson.)

  Same-origin policy and CORS

  Browsers enforce the same-origin policy: a page from one origin (scheme, host and port) cannot read responses from another origin. CORS (cross-origin resource sharing) is how a server opts in to being read by specific other origins.

  100%

  Figure SDA-NSD-04-2 · A cross-origin request with a preflight · © forcsguy.com

  Key points:

  • CORS protects users' browsers, not your server. It does not stop curl, scripts or other servers from calling your API; you still need authentication and authorisation.
  • A simple request (GET or simple POST with plain headers) is sent directly; the browser only decides whether the page may read the response. Other requests get a preflight.
  • Configure exact origins, not *, when credentials are involved. Access-Control-Allow-Credentials: true cannot be combined with *. Never blindly echo the Origin header.
  • Limit allowed methods and headers; cache preflights with Access-Control-Max-Age.

  Security headers worth sending

  Header	Purpose
  Strict-Transport-Security	Tell browsers to use HTTPS only for your domain
  Content-Security-Policy	Restrict script, style, frame and connection sources; mitigates XSS and clickjacking
  X-Content-Type-Options: nosniff	Stop browsers guessing content types
  Referrer-Policy	Limit referrer information sent to others
  Permissions-Policy	Turn off powerful browser features you do not use
  Cross-Origin-Opener-Policy / Cross-Origin-Resource-Policy	Isolate your pages from other origins

  Caching headers and compression

  • Cache-Control controls caching: public, max-age=31536000, immutable for fingerprinted static files; no-store for sensitive responses; private for per-user responses that shared caches must not store. ETag / Last-Modified allow cheap revalidation (a 304 response with no body).
  • Compression (gzip, Brotli) shrinks text responses a lot. One caution: compressing responses that mix secrets with attacker-controlled text over TLS can enable attacks such as BREACH, so avoid reflecting secrets and use per-request tokens.
  • Do not cache authenticated pages in shared caches by accident; set Vary correctly.

  Checklist

  Cookies: HttpOnly, Secure, SameSite. Tokens: short-lived, verified fully, no secrets inside. CORS: exact origins, minimal methods. Headers: HSTS, CSP, nosniff, frame protection. Caching: private or no-store for user data.

  Real-world reading

  Related reading

  • MDN: Cross-Origin Resource Sharing (CORS)MDN contributors · MozillaDocumentation
  • Introduction to JSON Web TokensAuth0 · jwt.ioDocumentation
  • RFC 6749: The OAuth 2.0 Authorization FrameworkIETFDocumentation
  • MDN: HTTP cachingMDN contributors · MozillaDocumentation

  Show 6 moreShow fewer

  • HTTP/3: the past, the present, and the futureCloudflareBlogs
  • System Design 101ByteByteGo · ByteByteGoHqGitHub
  • High Performance Browser NetworkingIlya Grigorik · O'ReillyBooks
  • RFC 9114: HTTP/3IETFDocumentation
  • Distributed SecurityMicrosoft engineers · MicrosoftCase Studies
  • TripAdvisor Architecture - 40M Visitors, 200M Dynamic Page Views, 30TB Data - High Scalability -High Scalability engineers · High ScalabilityCase Studies

  Open this lesson with its quiz and exercise