security glossary
short definitions for the security language used throughout the writing.28 terms · four practical categoriesidentity & access
who a caller is, how that identity persists, and what it may do.- authenticationAuthentication establishes an identity using evidence such as a password, hardware key, certificate, or signed token. It answers who is making the request, not what that identity may do.
also: authn · identity verification - authorizationAuthorization evaluates identity, role, relationships, resource state, and policy before allowing an operation. Sensitive decisions must be enforced by the server, not inferred from the interface.
also: authz · access control - principalA principal is the entity represented to an authorization system. Reliable access decisions require the server to establish that principal before evaluating roles, memberships, or object permissions.
also: security principal · authenticated actor - sessionA session binds later requests to authenticated state. Its identifier or claims should be unpredictable or integrity-protected, narrowly scoped, expiring, revocable, and transported securely.
also: authenticated session · login session - least privilegeLeast privilege limits both routine access and the damage caused by mistakes or compromise. Permissions should be specific to the task, resource, tenant, and time window instead of broadly inherited.
also: principle of least privilege · PoLP - default denyA default-deny model treats missing roles, relationships, claims, or policy results as a denial. New routes and unhandled states therefore fail closed instead of becoming silently public.
also: deny by default · default-deny - account takeoverAccount takeover occurs when an attacker can authenticate or act as the victim, commonly through stolen credentials, exposed reset tokens, session theft, or a broken recovery flow.
also: ATO · account compromise
web & browser
boundaries enforced around HTTP, origins, scripts, and navigation.- same-origin policyThe same-origin policy limits how one origin can read or manipulate resources from another. Controlled exceptions exist, but an application must not treat the browser boundary as a substitute for server authorization.
also: SOP · same origin policy - CORSCross-Origin Resource Sharing lets a server grant selected origins browser access to a response. It is a response-reading policy, not authentication, and loose reflection can expose credentialed data.
also: cross-origin resource sharing - CSRFCross-Site Request Forgery abuses credentials that a browser attaches automatically. Defenses include same-site cookies, unpredictable request tokens, origin checks, and requiring non-simple request formats.
also: cross-site request forgery · XSRF - XSSCross-Site Scripting lets untrusted content execute with an application's browser origin. Context-aware output encoding, safe DOM APIs, sanitization, and a restrictive CSP reduce the risk.
also: cross-site scripting - content security policyContent Security Policy narrows the resources and execution paths available to a document. A strict policy can contain injection impact and report violations, but it complements rather than replaces safe rendering.
also: CSP · Content-Security-Policy - open redirectAn open redirect allows a caller to send users from a trusted origin to an attacker-chosen location. It becomes more serious inside login, password-reset, invitation, or token-bearing flows.
also: unvalidated redirect · external redirect - SSRFServer-Side Request Forgery turns a trusted backend into a network client for untrusted input. It may expose internal services, cloud metadata, local files, or privileged network paths.
also: server-side request forgery
architecture & trust
how systems divide authority, tenants, components, and failures.- trust boundaryA trust boundary marks where identity, validation, confidentiality, or authority must be reconsidered. Browser-to-server, tenant-to-tenant, service-to-service, and public-to-private transitions are common examples.
also: trust boundaries · security boundary - tenant isolationTenant isolation binds each read and write to the authenticated principal's permitted tenant context. A tenant identifier supplied by the client may select a resource, but cannot grant authority to it.
also: multi-tenant isolation · tenant separation - object-level authorizationObject-level authorization evaluates ownership, tenant membership, role, relationships, and object state for each operation. Route-level authentication alone cannot establish access to every object behind the route.
also: object authorization · broken object level authorization · BOLA - IDORAn Insecure Direct Object Reference occurs when a request exposes an object identifier but the server fails to verify that the current principal may read or modify that object.
also: insecure direct object reference - confused deputyIn a confused-deputy failure, a service has legitimate authority but cannot distinguish which caller or purpose should receive it. Explicit capability binding and caller-aware authorization prevent the misuse.
also: confused-deputy problem - attack surfaceAn attack surface includes public and internal endpoints, background jobs, files, credentials, dependencies, administrative tools, and trust relationships. Reducing it removes opportunities before individual controls are tested.
also: exposed surface · attackable surface - defense in depthDefense in depth combines preventative, detective, and recovery controls across identities, applications, networks, data, and operations. The layers should fail independently rather than repeat the same assumption.
also: layered security · defence in depth
testing & operations
how findings are demonstrated, fixed, retested, and recorded.- threat modelA threat model identifies what must be protected, who may attack it, how data and authority move, and which controls address credible scenarios. It should evolve with the system rather than remain a launch document.
also: threat modeling · threat modelling - proof of conceptA security proof of concept records the minimum request, state, and response needed to verify a finding. Good evidence avoids unnecessary data access, destructive actions, and reusable exploitation material.
also: PoC · security proof of concept - responsible disclosureResponsible or coordinated disclosure gives the affected operator actionable evidence, impact, and remediation guidance while limiting unnecessary exposure. Publication timing should reflect risk and the communication record.
also: coordinated vulnerability disclosure · CVD - remediationRemediation includes the durable code or configuration fix plus containment, credential rotation, data review, logging, and sibling-system checks where relevant. Hiding one symptom is not a complete repair.
also: security fix · corrective action - retestA retest confirms the reported path is closed, intended users still work, unauthorized variants fail safely, and equivalent routes do not retain the same root cause. It records evidence against explicit acceptance criteria.
also: remediation validation · verification test - audit logAn audit log supports investigation and accountability by recording who did what, to which resource, when, from where, and whether it succeeded. Sensitive logs need integrity, access control, and retention limits.
also: audit trail · security event log - secret rotationSecret rotation creates a new value, updates consumers safely, revokes the old value, and checks for prior misuse. Deleting an exposed file without invalidating its credentials leaves the original risk active.
also: credential rotation · key rotation