Security

The set of policies and mechanisms that decide which users or processes can view, create, modify, or delete resources. Access control sits above authentication (confirming identity) and is implemented through models such as RBAC, ABAC, or access-control lists. Failures — privilege escalation, horizontal movement between user accounts, bypassing function-level checks — are consistently the most widespread class of security vulnerability. Test strategy: exercise every protected action with at least three privilege levels: the allowed role, a lower-privileged role, and unauthenticated.

A tamper-resistant record of important system and user actions — who did what, to what, and when. Audit logs support detection, investigation and accountability, especially for sensitive actions like role changes, deletions, admin operations and failed logins. For QA, the check is simple but often missed: perform a sensitive action and confirm a corresponding audit-log entry exists with the actor, action and timestamp.

A small name-value string the browser stores and automatically attaches to every request matching the cookie's domain and path. Set by the server via the Set-Cookie response header; read by the server from the Cookie request header; readable by JavaScript via document.cookie unless the HttpOnly flag is set. Key security attributes: HttpOnly (blocks JS access, mitigating XSS token theft); Secure (HTTPS-only transmission); SameSite (controls cross-site attachment — Strict, Lax, or None); Domain and Path (request scope). QA testing checklist: session cookies must have HttpOnly and Secure; auth cookies should be SameSite=Lax or Strict; sensitive data should not be stored in cookie values unencrypted; cookies should expire or be cleared on logout.

An attack that tricks an authenticated user's browser into sending a state-changing request to a site they are logged into, without their knowledge. Because the browser automatically attaches session cookies, the target server sees a legitimate-looking request. Classic mitigations: synchroniser tokens (a server-issued nonce added to forms and verified on submission), SameSite cookie attributes, and checking the Origin or Referer header. From a QA perspective: every state-changing endpoint (POST, PUT, PATCH, DELETE) should require a valid CSRF token or rely on SameSite=Strict/Lax cookies.

Probing a running application from the outside — like an attacker would — to find vulnerabilities such as injection flaws and misconfigured headers. Complements SAST, which only sees code.

The process of confirming that a user controls the email address they registered with, typically by sending a one-time link or code that must be clicked or entered before account features are unlocked. Security test cases include: link expiry (unclicked links should expire quickly), single-use enforcement (links must be invalidated after first use), account enumeration through timing differences, and whether unverified accounts can access protected resources. Re-verification flows when a user changes their email address are also in scope.

Feeding malformed, random, or unexpected inputs to a system to expose crashes, memory issues, and security flaws. Effective at finding bugs that hand-written tests miss because real users would never type such inputs.

A cryptographic construction that produces a fixed-length authentication tag from a message and a shared secret key, using a hash function (typically SHA-256). Unlike a plain hash, the secret prevents an attacker who doesn't know the key from forging a valid tag — even if they intercept the payload. HMAC-SHA256 is the standard webhook signature scheme used by Stripe, GitHub, Shopify, and most webhook providers: the sender signs the payload with the shared secret; the receiver recomputes HMAC(payload, shared_secret) and compares it to the signature header value. Testing considerations: verify the receiver recomputes independently (not just trusts the header), test correct signature → accepted, incorrect signature → 4xx, tampered payload → rejected, replayed valid signature after the expiry window → rejected.

A vulnerability where an application exposes internal object identifiers — database primary keys, file paths, account numbers — and fails to verify that the caller is authorised to access the referenced object. Example: user A requests GET /api/orders/1042; simply changing the ID to 1043 returns another user's order. IDORs are consistently one of the most prevalent API vulnerabilities (OWASP API Security Top 10: Broken Object Level Authorization). Testing: for every endpoint that accepts a resource ID, verify with a second authenticated account that it cannot access the first account's resources.

Checking user-supplied input before it is processed or stored, accepting only what a feature is designed to handle and safely rejecting or escaping everything else. Validation covers required fields, data types, length, format and allowed characters, and must be enforced server-side — browser-side validation is easily bypassed. For QA, varying input along these dimensions (very long text, special characters, HTML-like input, invalid dates) confirms the app handles unexpected input without breaking or storing unsafe content.

An authentication mechanism that requires at least two independent verification factors: something you know (password), something you have (TOTP app, hardware key), or something you are (biometric). MFA dramatically reduces the risk of credential-stuffing and phishing attacks. QA considerations include: testing fallback flows when a second factor is unavailable, recovery code handling, bypass scenarios via account recovery that skips MFA, and verifying MFA is checked on every protected action — not just at initial login.

Open Worldwide Application Security Project — a non-profit publishing free security guidance, including the OWASP Top 10 list of the most critical web application risks. The default reference for application security testing.

The flow that lets a user regain access when their credentials are lost or compromised. Typically involves verifying identity through a registered email or phone (a reset link or OTP), then allowing the user to set a new password. Security test cases include: token expiry (links should expire quickly), token single-use enforcement (used tokens must be invalidated), account enumeration (the response should not reveal whether an email is registered), brute-force protection on OTP entry, and ensuring reset tokens cannot be reused across accounts.

Authorised, simulated attacks against a system to find security weaknesses. Usually performed by security specialists late in the lifecycle, complementing automated scanning rather than replacing it.

The design rule that every user, role, token or service should have only the minimum access it needs to do its job — and nothing more. Applied well, a compromised account or a missing check causes limited damage. For QA, least privilege turns into concrete checks: confirm a read-only role cannot write, a normal user cannot reach admin functions, and a token carries only the permissions the account should have.

The SameSite attribute on a Set-Cookie header controls whether the browser sends the cookie on cross-site requests. Three values: Strict (cookie sent only on same-site requests — most restrictive, breaks some OAuth redirect flows); Lax (cookie sent on same-site requests and top-level navigations — the browser default since 2020); None (cookie sent on all requests including cross-origin — requires the Secure flag or modern browsers silently drop it). Testing checklist: session and auth cookies should be Lax or Strict; cross-origin API clients that send cookies must use SameSite=None; None without Secure is a common misconfiguration that causes silent cookie rejection rather than an error response.

Analysing source code or compiled artifacts for security flaws without running the application. Integrates into CI to catch issues early. Strong on logic and pattern bugs (hardcoded secrets, unsafe APIs); blind to runtime behaviour.

HTTP response headers that instruct the browser to apply protective behaviour — for example Content-Security-Policy (limits where scripts can load from), Strict-Transport-Security (forces HTTPS), X-Content-Type-Options and X-Frame-Options (limits framing/clickjacking). They are a cheap, high-value defence layer. QA can inspect responses in the browser network panel or an API tool and flag missing or misconfigured headers on key pages.

Leaking private or confidential data — passwords, tokens, personal data, payment-card data or internal details — through responses, logs, error messages, tokens or insecure storage. It is one of the most common high-impact issues QA can catch: confirm that sensitive values are masked in the UI and API responses, are not present in JWT payloads, and do not appear in stack traces. When reporting, mask the values themselves so the bug report does not become a second exposure.

The process of recomputing a cryptographic signature from a known algorithm, key, and payload, then comparing the result to the signature provided by the sender. If they match, the payload is authentic (originated from a party holding the secret) and unmodified in transit. Webhook signature verification uses HMAC-SHA256: the receiver recomputes HMAC(payload, shared_secret) and compares it to the signature header (e.g. X-Hub-Signature-256, Stripe-Signature, X-Shopify-Hmac-Sha256). Testing checklist: correct signature → accepted (200); tampered payload with original signature → rejected (401/400); missing signature header → rejected; signature for a different payload → rejected; replayed valid signature after expiry window → rejected.

An attack where untrusted input is concatenated into a SQL query, letting an attacker exfiltrate or modify data. Mitigated with parameterised queries and ORM usage. Tested with crafted payloads at every input that reaches the database.

Automated scanning of code, dependencies, or running systems for known security weaknesses (CVEs, misconfigurations). Cheap, continuous, and noisy — best paired with manual penetration testing for deeper coverage.

An attack where attacker-controlled JavaScript executes in another user's browser, often via unescaped input rendered into HTML. Categories include reflected, stored, and DOM-based. Mitigated by output encoding and a strict Content Security Policy.