API Security

A short-lived credential a client sends with each request to access protected resources, often a JWT carried in an Authorization header. Because it grants access, it must be transmitted securely, expire reasonably, and never contain sensitive data in a readable payload. QA checks: a missing, invalid or expired access token is rejected with 401, and a token belonging to one user cannot access another user's data.

The process of determining what an authenticated caller is permitted to do. Where authentication answers "who are you?", authorization answers "what are you allowed to do?" Common models include role-based access control (RBAC), attribute-based access control (ABAC), and scope-based delegation (OAuth). Testing authorization means verifying that every protected action enforces its policy — including negative cases where a lower-privileged user is explicitly denied access rather than silently downgraded.

Ranked #1 in the OWASP API Security Top 10. A BOLA (also called IDOR — Insecure Direct Object Reference) vulnerability exists when an API trusts the object ID in the request rather than checking whether the authenticated user is authorised to access that specific resource. Test by replacing `/users/1/orders/100` with `/users/1/orders/101` (an order belonging to a different user) — a vulnerable API returns a 200; a secure one returns a 403 or 404. The fix is server-side authorisation checks on every object access.

JSON Web Token — a compact, URL-safe token format for transmitting claims between parties. A JWT has three Base64URL-encoded sections separated by dots: header (signing algorithm), payload (claims like `sub`, `exp`, `roles`), and signature. Because the payload is encoded but not encrypted, any holder of the token can read the claims — never store secrets in a JWT payload. Test JWTs by checking expiry enforcement, algorithm validation (reject `alg: none`), and rejection of tampered signatures.

An open delegation protocol that lets users grant third-party applications scoped access to their resources without sharing their password. OAuth 2.0 defines four grant flows — Authorization Code (web apps), Client Credentials (server-to-server), Device Code (CLI tools / TVs), and PKCE (mobile apps). QA engineers test OAuth flows by validating token exchange, scope enforcement, refresh token behaviour, and failure modes like expired tokens, insufficient scopes, and revoked access.

A discrete, named right to perform a specific action on a resource — for example, orders:read, users:delete, or admin:manage-billing. Permissions are the atomic unit of access control; roles (RBAC) are collections of permissions granted to a group. In testing, each permission must be verified in isolation: a user with orders:read but not orders:write should receive a 403 on write operations, not a 200 or a 404 that obscures the enforcement failure.

Role-Based Access Control — a permission model where access rights are assigned to roles, and users inherit permissions by belonging to one or more roles. A `viewer` role can read resources; an `admin` role can create, update, and delete. In API testing, RBAC tests verify that each role can reach only the endpoints it should: a viewer calling `DELETE /content` should get a 403, not a 200. Broken access control at the object and function level is consistently in the OWASP API Security Top 10.

A longer-lived credential used to obtain a new access token when the current one expires, without forcing the user to log in again. Because it is more powerful than an access token, it should be stored securely, be revocable, and be invalidated on logout or password change. QA checks: after logout or a password reset, a previously issued refresh token can no longer mint new access tokens where the product requires it.

A server-side or client-side record that persists a user's authenticated state across requests. Sessions are created on login, referenced by a session ID sent in a cookie or header, and invalidated on logout or expiry. Testing considerations include: session fixation (attacker sets the victim's session ID before login), failure to rotate the ID after privilege escalation, excessively long session lifetimes that extend exposure after credential compromise, and whether logout actually invalidates the server-side session.

An attack where an attacker tricks a server into making HTTP requests on their behalf — often to internal services that aren't exposed to the internet. A vulnerable endpoint accepts a URL as input and fetches it server-side. Attackers use SSRF to reach cloud metadata endpoints (`http://169.254.169.254/latest/meta-data/`), internal admin interfaces, and databases. Test by supplying internal IPs, `localhost`, or cloud metadata URLs as inputs. The fix is a strict allowlist of permitted destination hosts.

A portable credential — typically a signed string — that a server issues and a client presents on subsequent requests to prove identity or authorisation. Tokens are stateless alternatives to server-side sessions; the server can verify them without a database lookup. Common forms: opaque bearer tokens (random strings referenced in a database), JWTs (self-contained with claims and a signature), and OAuth access tokens (short-lived grants scoped to specific resources). Key testing considerations: token expiry, revocation, scope enforcement, and transmission security (HTTPS-only, no logging).