Security & Access Fundamentals

Security & Access Fundamentals

Use this page to revise the concepts behind keeping an application's users and their data safe: who someone is, what they're allowed to do, and how you stop bad input from causing harm.

Authentication vs. authorization

Authentication answers "who are you?"; authorization answers "what are you allowed to do?". They're solved separately, and mixing them up is a common source of security bugs (e.g. checking that someone is logged in, but not that they're allowed to access this specific resource).

Session- and token-based authentication

• Session-based authentication stores session state on the server and gives the client a cookie referencing it.
• Token-based authentication (JWT) encodes the session state itself into a signed token, containing claims (data about the user), a signature (proving it wasn't tampered with), and an expiry (so it can't be replayed forever).

Password storage

Passwords must never be stored in plain text. Hashing turns a password into a fixed-length value that can't practically be reversed; salting adds random data per password before hashing, so identical passwords don't produce identical hashes. bcrypt and Argon2 are standard libraries that handle both correctly.

Role-based access control

Role-based access control (RBAC) assigns permissions to roles (e.g. "admin", "user") rather than to individual users, and checks a user's role before allowing a sensitive action or route.

Input validation

• Allow-list vs. deny-list validation: an allow-list only accepts input matching a known-good pattern; a deny-list tries to block known-bad input. Allow-lists are safer, because they don't depend on anticipating every possible attack.
• Server-side validation is mandatory even if client-side validation exists, because a client can always be bypassed.
• Output encoding/sanitisation makes sure data is safe for the context it's displayed or used in (e.g. escaping HTML so user input can't inject a script tag).

SQL injection and XSS

• SQL injection happens when untrusted input is concatenated directly into a SQL query; parameterised queries (or ORM parameter binding) prevent it by keeping data and query structure separate.
• Cross-Site Scripting (XSS) happens when untrusted input is rendered as HTML/JS without encoding, letting an attacker run script in another user's browser. Prevention relies on the output encoding described above, applied consistently at every point user input is rendered.

Starting Points

• LinkedIn Learning. Web Security: User Authentication and Access Control.
• JWT Handbook. jwt.io.
• OWASP Cheat Sheet Series. Input Validation, SQL Injection Prevention, XSS Prevention.
• Authentication & authorization basics
• Input validation & secure coding
• Web security fundamentals

Key Points

• You can explain the difference between authentication and authorization.
• You can explain the difference between session-based and token-based (JWT) authentication.
• You can explain why passwords must be hashed and salted, not stored in plain text.
• You can explain what role-based access control is.
• You can explain the difference between allow-list and deny-list validation, and why server-side validation is required.
• You can explain how parameterised queries prevent SQL injection.
• You can explain what XSS is and how output encoding prevents it.