Security Headers
// Definition
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.
// Related terms
CORS
Cross-Origin Resource Sharing — a browser security mechanism that restricts web pages from making HTTP requests to a domain different from the one that served the page. The browser preflight-checks cross-origin requests by sending an `OPTIONS` request; the server responds with `Access-Control-Allow-Origin` (and related) headers to grant or deny access. For API testers: misconfigured CORS is a common security vulnerability, and missing CORS headers cause silent failures in browser-based test environments.
XSS (Cross-Site Scripting)
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.
CSRF (Cross-Site Request Forgery)
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.