Access Control

Access control is the set of mechanisms that decide whether a given subject (user, service, or token) may perform a given action on a given resource. On the web it combines authentication (who you are) with authorization (what you may do), and is the category behind OWASP's "Broken Access Control" risk. Enforce it server-side on every request, never by hiding a button in the UI.

Authentication

Authentication is the process of verifying that a principal is who it claims to be, typically via a password, a passkey, a one-time code, or a cryptographic key. It establishes identity but says nothing about permissions, which is authorization's job. Weak or missing authentication (credential stuffing, no MFA, predictable session IDs) is a top cause of account takeover.

Authorization

Authorization determines what an authenticated principal is allowed to do, enforcing rules such as role-based or attribute-based access control. Every protected operation must re-check authorization on the server using the server's notion of identity, not a client-supplied role or object ID. Failing to do so produces broken access control, including IDOR.

Broken Object Level Authorization (BOLA)

BOLA, also called IDOR, occurs when an API exposes an object identifier and fails to verify that the caller is allowed to access that specific object. An attacker simply changes the ID in the request (for example from /orders/123 to /orders/124) to read or modify another tenant's data. It is the number-one risk in the OWASP API Security Top 10.

Brute Force Attack

A brute force attack tries many credentials or values systematically until one works, for example guessing passwords, session tokens, or TOTP codes. Defences include rate limiting, account lockout or throttling, strong password policies, MFA, and high-entropy tokens. Credential stuffing is a targeted variant that replays username/password pairs leaked from other breaches.

Certificate Authority (CA)

A certificate authority is a trusted entity that issues digital certificates binding a public key to an identity such as a domain name. Browsers ship with a root store of trusted CAs; a TLS certificate is trusted if it chains to one of those roots and is unexpired and unrevoked. Let's Encrypt is a widely used CA offering free, automated, short-lived certificates.

Clickjacking

Clickjacking tricks a user into clicking something different from what they perceive by overlaying or framing a target site inside an attacker page, usually with a transparent iframe. The user thinks they are interacting with the attacker's UI but their clicks land on the framed site. It is mitigated by sending a restrictive Content-Security-Policy: frame-ancestors directive (or the legacy X-Frame-Options).

Content Security Policy (CSP)

Content Security Policy is an HTTP response header that tells the browser which sources of script, style, images, and other content are allowed to load and execute. A strict, nonce- or hash-based script-src is one of the most effective defences against cross-site scripting, because injected inline scripts without the correct nonce are blocked. CSP is defence in depth, not a substitute for output encoding.

CORS is a browser mechanism that relaxes the same-origin policy in a controlled way, letting a server opt in to cross-origin requests via Access-Control-Allow-Origin and related headers. It is enforced by the browser, not the server, and protects users - it is not an authentication or server-side access-control mechanism. Reflecting the request's Origin with credentials enabled is a common dangerous misconfiguration.

Cross-Site Request Forgery (CSRF)

CSRF forces a logged-in user's browser to send an unintended state-changing request to a site where they are authenticated, abusing the browser's automatic inclusion of cookies. It is mitigated with anti-CSRF tokens (synchronizer or double-submit) and the SameSite cookie attribute. CSRF targets cookie-based session auth; APIs that authenticate with a bearer token in a header are generally not exposed to it.

Cross-Site Scripting (XSS)

XSS is an injection flaw in which an attacker gets the browser to execute attacker-controlled script in the context of a trusted site, letting them steal session tokens, perform actions as the user, or deface pages. The three classic forms are stored, reflected, and DOM-based XSS. The primary defence is context-aware output encoding plus a strict Content Security Policy.

Defense in Depth

Defense in depth layers multiple independent controls so that the failure of one does not compromise the whole system. For a web app this means input validation, output encoding, parameterized queries, least-privilege accounts, network segmentation, and monitoring all working together. No single control (such as a WAF) should be treated as sufficient on its own.

DOM-based XSS

DOM-based XSS is a cross-site scripting variant where the vulnerability lives entirely in client-side JavaScript, which takes attacker-controllable data from a source (such as location.hash) and passes it to a dangerous sink (such as innerHTML or eval) without sanitization. Because the payload may never reach the server, server-side filtering does not stop it. Use safe sinks like textContent and framework-provided binding instead.

Encryption at Rest

Encryption at rest protects stored data - databases, backups, disks, object storage - so that physical theft or unauthorized access to the storage layer does not expose plaintext. It is distinct from encryption in transit (TLS), and both are usually required. Key management, not the cipher, is the hard part: keys must be stored and rotated separately from the data they protect.

HTTP Strict Transport Security (HSTS)

HSTS is a response header (Strict-Transport-Security) that instructs the browser to only contact a site over HTTPS for a specified period, preventing protocol-downgrade and SSL-stripping attacks. Once a browser has seen the header, it refuses plain-HTTP connections to that host even if the user types http://. Preloading adds the domain to a browser-shipped list so the first request is also protected.

IDOR (Insecure Direct Object Reference)

IDOR is broken access control where the application uses user-supplied input to access an object directly without checking that the user is authorized for it. Synonymous in practice with Broken Object Level Authorization, it lets attackers enumerate and reach other users' records by altering an identifier. The fix is a server-side ownership/permission check on every object access, not unguessable IDs alone.

Injection

Injection flaws occur when untrusted data is sent to an interpreter (SQL, OS shell, LDAP, NoSQL, template engine) as part of a command or query, allowing the attacker to alter its meaning. SQL injection and command injection are the classic examples. The robust defence is to keep code and data separate using parameterized queries, safe APIs, and allow-list input validation.

JSON Web Token (JWT)

A JWT is a compact, URL-safe, signed (and optionally encrypted) token carrying claims as a JSON payload, commonly used for stateless authentication and authorization. It has three Base64url parts - header, payload, signature - separated by dots; the payload is signed, not secret, so never put confidential data in it unencrypted. Always verify the signature and reject the alg: none value and unexpected algorithms.

Least Privilege

The principle of least privilege states that every user, process, and service account should have only the permissions strictly necessary to do its job, and no more. Applied to web apps it means scoped API tokens, database users restricted to needed tables, and short-lived credentials. It limits the blast radius when any single component is compromised.

Multi-Factor Authentication (MFA)

MFA requires two or more independent factors to authenticate: something you know (password), something you have (a security key or authenticator app), or something you are (biometric). It dramatically reduces account takeover from phishing and credential stuffing because a stolen password alone is insufficient. Phishing-resistant MFA based on WebAuthn/FIDO2 is stronger than SMS or TOTP codes.

OAuth 2.0

OAuth 2.0 is an authorization framework that lets an application obtain limited, delegated access to a user's resources on another service without handling the user's password, by exchanging an authorization grant for an access token. It is for delegated authorization, not authentication; OpenID Connect is the identity layer built on top of it. Public clients should use the Authorization Code flow with PKCE.

OpenID Connect (OIDC)

OpenID Connect is an authentication layer built on OAuth 2.0 that adds an ID token (a signed JWT) describing the authenticated user, plus a standardized userinfo endpoint and discovery document. It lets relying parties verify a user's identity and obtain basic profile claims from an identity provider. OIDC answers "who is the user?" whereas plain OAuth answers "what may this app access?".

Output Encoding

Output encoding transforms data so that it is rendered as inert text rather than executable code in the context where it appears (HTML body, HTML attribute, JavaScript, URL, CSS). It is the primary defence against cross-site scripting and must be context-aware, because the correct escaping differs per context. Modern frameworks encode by default, but raw HTML sinks bypass that protection.

Parameterized Query

A parameterized query (prepared statement) sends the SQL command structure and the user-supplied values to the database separately, so the values can never be interpreted as SQL code. It is the definitive defence against SQL injection and should be used for every query containing variable data. String concatenation to build SQL is the anti-pattern it replaces.

PKCE (Proof Key for Code Exchange)

PKCE is an OAuth 2.0 extension that protects the authorization code flow against interception by binding the code exchange to a per-request secret. The client sends a hashed code_challenge when requesting the code and the matching code_verifier when redeeming it, so a stolen authorization code is useless to an attacker. It is mandatory for public clients (SPAs, mobile) and recommended for all clients in OAuth 2.1.

Rate Limiting

Rate limiting caps how many requests a client may make in a time window, throttling or rejecting excess traffic to protect against brute force, credential stuffing, scraping, and denial-of-service. It can key on IP, account, API key, or token, and is often implemented with token-bucket or sliding-window algorithms. Pair it with exponential backoff and clear 429 Too Many Requests responses.

Same-Origin Policy (SOP)

The same-origin policy is the foundational browser security model that restricts how a document or script loaded from one origin can interact with resources from another origin, where origin is the tuple of scheme, host, and port. It prevents a malicious page from reading another site's responses or DOM. CORS is the controlled mechanism for relaxing it for specific cross-origin requests.

SameSite is a cookie attribute that controls whether the cookie is sent on cross-site requests, with values Strict, Lax, and None. Lax (a common default) blocks the cookie on cross-site subrequests and form POSTs while allowing top-level navigations, providing meaningful CSRF defence. None requires the Secure flag and sends the cookie cross-site, which is needed for some third-party integrations.

The Secure, HttpOnly, and SameSite attributes harden session cookies: Secure restricts the cookie to HTTPS, HttpOnly hides it from JavaScript (limiting XSS-based theft), and SameSite constrains cross-site sending (limiting CSRF). Session cookies should normally set all three. The __Host- prefix additionally enforces Secure, no Domain, and Path=/.

Security Misconfiguration

Security misconfiguration is the risk of insecure default settings, incomplete configurations, verbose error messages, unused features left enabled, or missing security headers. It is one of the most common and easily exploited web risks because it does not require a coding flaw. Hardening baselines, automated configuration scanning, and removing defaults reduce it.

Server-Side Request Forgery (SSRF)

SSRF tricks a server into making HTTP requests to a destination chosen by the attacker, often to reach internal services, cloud metadata endpoints, or otherwise unreachable hosts. It is dangerous in cloud environments where the metadata service (169.254.169.254) can yield credentials. Mitigate with strict allow-lists of destinations, blocking link-local and internal ranges, and disabling unused URL schemes and redirects.

Session Fixation

Session fixation is an attack where the attacker sets or knows a victim's session identifier before login and then hijacks the authenticated session afterward. The fix is to issue a brand-new session ID at the moment privilege changes - most importantly immediately after successful authentication - and invalidate the old one. Never accept session IDs supplied in the URL.

Session Management

Session management is how an application establishes, maintains, and terminates the authenticated state of a user across stateless HTTP requests, typically via a session cookie or token. Secure sessions use high-entropy identifiers, rotate the ID on login, set secure cookie attributes, enforce idle and absolute timeouts, and invalidate on logout. Weak session management enables hijacking and fixation.

SQL Injection (SQLi)

SQL injection is an injection flaw where attacker-controlled input alters the structure of a SQL query, allowing data theft, modification, authentication bypass, or in some cases command execution. It remains among the most damaging web vulnerabilities. The reliable fix is parameterized queries (prepared statements) with least-privilege database accounts and allow-list validation as defense in depth.

Subresource Integrity (SRI)

Subresource Integrity lets a page guarantee that an externally hosted script or stylesheet has not been tampered with, by adding an integrity attribute containing a cryptographic hash of the expected file. The browser fetches the resource and refuses to execute it if the hash does not match. SRI defends against compromised CDNs and is typically paired with the crossorigin attribute.

Supply Chain Attack

A supply chain attack compromises software by targeting a trusted upstream dependency, build tool, or distribution channel rather than the target application directly. Examples include malicious npm packages, typosquatting, and compromised CI pipelines. Defences include lockfiles, dependency pinning and verification, SBOMs, least-privilege build systems, and Subresource Integrity for third-party scripts.

Threat Modeling

Threat modeling is a structured activity to identify, enumerate, and prioritize potential threats to a system early in design, so controls can be planned rather than bolted on. A common approach is STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) applied to a data-flow diagram. It answers what can go wrong and what to do about it.

TLS (Transport Layer Security)

TLS is the cryptographic protocol that secures data in transit between client and server, providing confidentiality, integrity, and server (optionally client) authentication; it underpins HTTPS. TLS 1.3 is the current recommended version, removing legacy ciphers and reducing the handshake to one round trip. Misconfiguration (weak ciphers, expired certificates, missing HSTS) undermines its protection.

Token Storage

Token storage is the decision of where a web client keeps credentials such as access and refresh tokens. localStorage is readable by any JavaScript on the page, so a single XSS can exfiltrate tokens; HttpOnly cookies are inaccessible to script but require CSRF defenses. The trade-off (XSS exposure vs CSRF surface) must be made deliberately, not by default.

WebAuthn / FIDO2

WebAuthn is a W3C standard, part of the FIDO2 project, that enables passwordless and phishing-resistant authentication using public-key cryptography and authenticators such as security keys, platform biometrics, or passkeys. The private key never leaves the authenticator and the signature is bound to the origin, defeating phishing and credential replay. It is the strongest widely available web authentication mechanism.

Web Application Firewall (WAF)

A WAF inspects HTTP traffic and blocks requests matching known attack patterns (SQLi, XSS, path traversal) before they reach the application. It provides useful defense in depth and virtual patching, but it is a filter that can be bypassed and must never replace secure coding. Treat WAF alerts as signal, not as a guarantee that the underlying flaw is fixed.

Zero Trust

Zero trust is a security model that assumes no implicit trust based on network location and instead verifies every request's identity, device, and context before granting access. "Never trust, always verify" replaces the old perimeter model where being inside the network meant being trusted. For web systems it implies per-request authentication and authorization, strong identity, and least privilege everywhere.