Web Security

🎯Learning Objectives

• Distinguish authentication from authorization, locate trust boundaries, and explain session, CSRF, XSS and injection defenses.
• Predict why a request is rejected before state changes.

🗺️Trust Boundaries and Threat Models

• List assets, callers, entry points and allowed actions before choosing controls.
• Browser inputs, hidden fields and client-side checks are untrusted.
• A trusted backend enforces decisions even when the UI is bypassed.

asset: private note
caller: anonymous / owner / other user
actions: read / update
expected denial: no private note returned

• Threat-model worksheet: Write expected outcomes first.
• If an API exposes several operations, build the matrix for each operation rather than testing only its page button.

🔑Authentication — Establish Identity

• Use a maintained authentication system.
• Store passwords with a suitable adaptive password hash such as Argon2id through a maintained library, with its salt handling.
• Plaintext, reversible encryption and fast general-purpose hashes are unsuitable defaults.
• Protect reset flows, add MFA where appropriate and limit guessing without leaking account existence.

identity = authentication_service.verify(credentials)
session = session_service.create(identity)
# Use maintained libraries; do not invent a password hash.

• Authentication flow — conceptual pseudocode: Keep credential verification separate from later object permissions.
• A valid password cannot decide which note an account owns.

🛡️Authorization — Check Every Object

• Deny by default and check the requested action and object on every request.
• A signed-in user is not allowed to read all notes.
• Query and update within the permitted ownership scope; never accept a submitted owner or role as authority.

SELECT id, text FROM notes
WHERE id = :note_id AND owner_id = :trusted_user_id;

• Ownership scope — conceptual database fragment: Bind both values using the actual driver.
• Obtain trusted_user_id from validated server identity, not submitted JSON.
• Scope writes similarly and check affected rows.

🍪Sessions and Cookies

• Use unpredictable session identifiers, regenerate on login and relevant privilege changes, and expire sessions server-side on logout and time limits.
• For cookie sessions configure Secure, HttpOnly and suitable SameSite and scope.
• HttpOnly restricts script access to cookies; it does not make XSS harmless.
• Avoid session identifiers in URLs.

Set-Cookie: session=<opaque-id>; Path=/; Secure; HttpOnly; SameSite=Lax

• Cookie attribute illustration: This header illustrates attributes, not a complete session implementation.
• Choose SameSite for the actual cross-site login and navigation requirements; invalidate sessions on the backend.

🎟️CSRF — Protect State-Changing Requests

• Browsers can attach cookies automatically.
• Use framework CSRF protection, a token tied to the session and checked by the backend, and appropriate origin verification.
• SameSite is defense in depth.
• Avoid state changes on GET; do not place CSRF tokens in URLs or logs.
• XSS can defeat these defenses, so output protection remains necessary.

resolve_active_session()
authorize_requested_note()
verify_framework_csrf_protection()
validate_writable_fields()
apply_authorized_update()

• Protected write — conceptual middleware order: Middleware order depends on the framework, but every required protection must precede mutation.
• Never treat a valid CSRF token as a permission grant.

🪟XSS — Render for the Correct Context

• For plain text, use textContent and fixed DOM elements.
• HTML, attributes, JavaScript and URLs have different rules; a single escape function is not universal protection.
• If rich HTML is required, use a maintained sanitizer with an appropriate policy.
• Avoid inserting untrusted strings into executable markup.

const paragraph = document.createElement("p");
paragraph.textContent = note.text;
preview.replaceChildren(paragraph);

• Plain text sink: For a note containing <Demo> & notes, the angle brackets remain visible.
• This fragment supports plain text; rich HTML needs a different, deliberate sanitized pipeline.

🗄️Injection — Separate Values from Instructions

• Bind SQL values with parameterized queries.
• Placeholder syntax depends on the database driver.
• Parameters do not substitute arbitrary table names or SQL keywords; dynamic identifiers require strict allowlists.
• Avoid shell concatenation and prefer safe APIs with fixed command structure.
• Validation alone does not make concatenated SQL safe.

UPDATE notes SET text = :text
WHERE id = :id AND owner_id = :trusted_user;

• Parameterized update — conceptual SQL: This is a driver-neutral illustration.
• Use real bound parameters, enforce affected-row behavior and transaction requirements, and do not splice text into this SQL string.

✅Validation and Writable Fields

• Bound input size before expensive parsing.
• Check syntax, expected object shape, types, lengths and domain rules.
• Accept only writable fields to prevent mass assignment of owner or role.
• Validation is separate from authorization, safe query construction and contextual output handling.

{"text":"Review trust boundaries"}

Reject: {"text":"New note","owner":"B","role":"admin"}

• Writable JSON contract: The lab rejects extra fields even when text is valid.
• In a real endpoint, parse only explicitly writable fields and apply domain rules after authentication and authorization.

🌐TLS and Browser Policy

• Use HTTPS and secure transport throughout the deployment.
• CORS controls browser cross-origin response access; it does not authenticate callers.
• A carefully tested Content Security Policy can limit script execution as an additional layer.
• Use frame-ancestors for a deliberate embedding policy.
• Develop CSP for the actual site and test reports rather than pasting a policy that breaks legitimate scripts.

TLS: is every protected request encrypted?
CORS: which browser origins may read responses?
CSP: which scripts may execute?
Authorization: may this caller access this object?

• Policy questions: Answer each question separately.
• Restrictive CORS cannot stop a non-browser client from sending requests to an inadequately protected backend.

🔒Secrets, Dependencies and Configuration

• Keep private keys and backend secrets out of frontend bundles and repositories.
• Use scoped secrets and rotate exposed credentials.
• Review dependencies and update vulnerable packages.
• Disable unnecessary services and debug endpoints; development settings are not automatically safe for production.

browser: public API URL, display options
backend: scoped database credential, signing secret
operations: secret rotation and dependency update process

• Configuration separation: A variable called SECRET in client JavaScript remains public.
• Restrict secret access and provide an operational rotation path.

📁Uploads, URLs and Server Fetches

• For uploads combine size limits, allowed types, content inspection, safe generated names, controlled storage and authorization.
• A claimed MIME type is untrusted.
• For server URL fetching prevent access to internal addresses and constrain redirects; use a maintained SSRF protection approach.
• Validate redirects against an explicit destination policy.

allowed extension + verified content
size limit + generated storage name
controlled storage + authorized retrieval

• Upload review checklist: No single check is enough.
• A filename, extension or client-supplied MIME label cannot establish that a file is harmless or authorized for public serving.

⏱️Abuse and Resource Limits

• Limit attempts and resource use at relevant boundaries.
• Consider account, caller and operation scope, expensive requests, concurrency and storage limits.
• A frontend maxlength is convenience; the server must enforce its own bounds.
• Avoid trusting arbitrary forwarding headers when determining callers.

input bytes: bounded at server boundary
request work: bounded per operation
attempt frequency: appropriate caller/account scope
concurrent work: controlled upstream and backend

• Resource budget worksheet: Test the outcome when each budget is exhausted.
• The visible textarea limit does not prevent a caller from crafting a larger direct request.

📝Logs, Errors and Privacy

• Use stable public errors and protected operational logs.
• Do not log passwords, session tokens or CSRF tokens.
• Avoid revealing whether another user’s private object exists.
• Retain only necessary data and protect log access.
• The lab state panel exposes fictional teaching data; it is not a pattern for a production debug endpoint.

public: This note is not available to this caller.
protected log: operation + correlation ID + permitted diagnostic
never: password, session token, CSRF token

• Public versus protected diagnostic: The lab deliberately uses the same public access message for a missing note and another owner’s note.
• Its fictional state panel is teaching instrumentation only.

🧪Verify the Security Boundary

• Test anonymous, expired and valid sessions, different owners, missing or stale tokens and malformed bodies.
• Confirm rejection leaves data unchanged.
• Test actual backend authorization, cookies, HTTPS, CSRF middleware and database operations independently.
• Successful local tests cannot certify a deployed application.

anonymous read → deny
owner read → allow
other-owner write → deny
owner write + stale token → deny
owner write + valid gates → allow

• Negative-case matrix: For every denied case snapshot stored state before and after.
• Add real integration checks for framework session cookies, CSRF middleware, database scope and concurrent writes.

🧪Premium Interactive — Protected Note Policy

• This local model has fictional notes owned by A and B.
• Select a trusted session fixture to simulate server-side identity: the selector itself is not real authentication.
• GET reads an owned note; POST updates it.
• DELETE is unsupported.
• Unknown and non-owned notes share one public access-denied message.

• POST requires exact expected origin https://learn.example and the selected active session’s current CSRF token.
• The visible predictable demo tokens teach matching and rotation only; production tokens must use the framework’s secure generation and verification.
• GET ignores origin, token and body and never mutates.

• POST accepts raw JSON up to 1,000 JavaScript code units, exactly text as a string trimmed to 1–120 Unicode code points without C0/C1 controls or lone surrogates.
• JSON.parse uses the last duplicate key; this model does not detect duplicate JSON keys.
• Rotate/expire clear previous results; reset restores all fixtures.
• No network, cookies, passwords or real accounts are used.

No request yet.

No trace yet.

No response yet.

No returned note.

🛠️Debugging — Find the First Failed Gate

• Check route and method, then session validity, object ownership, write origin/token and input contract.
• A valid token never grants access to another owner’s note.
• Fix the rejected boundary rather than removing the protection.

• After token rotation, copy the new token from the fictional state panel; an old token must fail.
• Expiration invalidates the fixture even if a token still appears in the input.
• An error must clear the previous note preview.

💬Interview Questions — Flip to Explain

❓MCQ Practice — Explain Security Decisions

💻Extra Practice — Predict the Security Decision

📌Quick Revision

📖Glossary — Flip to Learn

🏆Final Challenge — Protect a Private Note Feature

• Specify identity, ownership and writable fields for read and update.
• Use maintained session and CSRF infrastructure, bind database values, and render plain text safely.
• Keep logs and public errors appropriate to their audiences.

• Write negative tests for anonymous, expired, other-owner, wrong-origin, stale-token and invalid-body requests.
• Assert both denial and unchanged stored data.
• Implement authorization and mutation within the appropriate backend transaction or atomic operation.

• Verify actual cookies, HTTPS, origin handling, backend queries and deployment policy independently.
• Success means explaining which boundary each defense protects.
• Next: Level29 — Web Performance and Deployment.