Question 1

What is the difference between authentication and authorization?

Accepted Answer

Authentication (AuthN) and authorization (AuthZ) are sequential security steps that are often confused but solve distinct problems.

Authentication answers: who are you? It is the process of verifying that a claimed identity is genuine. A user presents credentials — a password, a cryptographic key, a hardware token, a biometric — and the system validates them against a stored record. Successful authentication establishes an authenticated identity. Mechanisms: password + hash comparison (bcrypt/argon2 on server side), OAuth 2.0 + OIDC for delegated authentication (Google/GitHub login), SAML for enterprise SSO, WebAuthn for passkeys, mutual TLS for service-to-service. After authentication, a session token or JWT is issued to represent the authenticated identity for subsequent requests.

Authorization answers: what are you allowed to do? It occurs after authentication and determines whether the authenticated identity has permission to perform a specific action on a specific resource. A user might be authenticated (the system knows who they are) but unauthorized to access a particular resource (they lack the required permission). Mechanisms: Role-Based Access Control (RBAC — roles assigned to users, permissions assigned to roles), Attribute-Based Access Control (ABAC — policies evaluate attributes of user, resource, and context), ACLs (per-resource permission lists), OAuth 2.0 scopes (token carries permitted actions). In REST APIs, authorization checks typically happen after validating the request's JWT/session token.

The practical consequence of conflating them: a system that only authenticates (checks that the user is logged in) but doesn't enforce fine-grained authorization will allow any authenticated user to access any resource — a classic BOLA (Broken Object Level Authorization) vulnerability. An attacker who is legitimately authenticated as user A modifies a request to access user B's data, and the server checks authentication (token is valid) but not authorization (does this token's user own this resource?).

The two-step flow in a typical web API: request arrives with a Bearer token → authentication middleware validates the token's signature and expiry → authorization layer checks whether the identity in the token has permission for the requested operation → request handler executes. These are separate concerns implemented at separate layers.

Question 2

What are the three parts of a JWT? How are they signed and revoked?

Accepted Answer

A JSON Web Token (JWT) is a compact, self-contained token format for transmitting claims between parties. It consists of three base64url-encoded parts separated by dots: header.payload.signature.

The header is a JSON object specifying the token type and signing algorithm: `{"alg": "HS256", "typ": "JWT"}`. Common algorithms: HS256 (HMAC-SHA256, symmetric key), RS256 (RSA-SHA256, asymmetric key pair), ES256 (ECDSA, asymmetric). The algorithm choice has security implications.

The payload contains claims — key-value assertions about the subject. Registered claims are standardized: `iss` (issuer), `sub` (subject/user ID), `exp` (expiration timestamp), `iat` (issued-at), `aud` (audience — which service this token is for). Custom claims add application-specific data: roles, permissions, user metadata. The payload is base64url-encoded but not encrypted — anyone can decode and read it. Never store sensitive data (passwords, PII) in JWT payloads unless the token is also encrypted (a JWE).

The signature is computed over the encoded header and payload: `HMAC-SHA256(base64url(header) + '.' + base64url(payload), secret)` for HS256. The server verifies the signature on each request to ensure the token hasn't been tampered with. If any part of the header or payload changes, the signature no longer matches.

For signing algorithm selection: HS256 uses one shared secret — simple but both issuer and verifier must know the secret, which is risky if multiple services verify tokens. RS256/ES256 use private key for signing (auth server only) and public key for verification (any service) — better for distributed systems. A critical vulnerability to know: the `alg: none` attack — early JWT libraries accepted tokens with algorithm `none` and no signature; always explicitly validate the expected algorithm.

Revocation is JWT's hard problem. JWTs are stateless — validity is proven by signature alone, with no server-side lookup. A revoked JWT remains valid until it expires unless you add state. Common patterns: short expiry (5-15 minutes) plus refresh tokens; a token blocklist/denylist (store revoked JTI claims in Redis — brings back state but bounded to revoked tokens only); or opaque tokens for critical paths where immediate revocation is required. Logout in JWT-based systems is often a client-side delete (remove the token from storage) plus server-side blocklist of the specific token if revocation must be immediate.

Question 3

What is SQL injection and how do you prevent it?

Accepted Answer

SQL injection is a vulnerability where an attacker supplies input that is interpreted as SQL syntax rather than data, allowing them to manipulate queries, bypass authentication, exfiltrate data, or destroy database contents.

The root cause is string concatenation of user input into SQL queries. Consider: `query = "SELECT * FROM users WHERE username='" + username + "'"`. If the attacker submits `' OR '1'='1`, the query becomes `WHERE username='' OR '1'='1'` — which is always true and returns all users. With `'; DROP TABLE users; --`, they can append destructive statements.

Attack classes: authentication bypass (as above), data exfiltration (UNION-based injection to read other tables), blind SQL injection (boolean or time-based — infer data character by character when output isn't returned), and second-order injection (malicious payload stored in the DB and used in a later query).

The primary prevention is parameterized queries (prepared statements). The query structure is compiled separately from the data values, and the database driver handles proper escaping. In Python with psycopg2: `cursor.execute("SELECT * FROM users WHERE username = %s", (username,))`. The second argument is always treated as data, never as SQL syntax — even if it contains quotes, semicolons, or SQL keywords. This is not string formatting; the placeholder mechanism is separate from the query text.

ORMs like SQLAlchemy and Django ORM use parameterized queries internally, so standard ORM usage is safe. The danger reappears when using raw SQL within ORMs — `session.execute(text(f"WHERE name = '{name}'"))` is unsafe; `session.execute(text("WHERE name = :name"), {"name": name})` is safe.

Additional defenses in depth: least-privilege database accounts (the app user shouldn't have DROP or admin privileges), input validation (reject unexpected characters for structured inputs like IDs), stored procedures with parameterization, and WAFs as a backstop (not a substitute). ORMs reduce surface area but don't eliminate risk from raw queries or dynamic order-by clauses.

SQLMap is the canonical automated tool for detecting and exploiting SQL injection. Running it against your own app in a test environment is a standard audit step. OWASP lists SQLi as part of the A03:2021 Injection category.

Question 4

What is CSRF and how do you prevent it?

Accepted Answer

Cross-Site Request Forgery (CSRF) is an attack where a malicious site causes an authenticated user's browser to send a forged request to a target site. Because browsers automatically attach cookies to same-origin requests, the target server cannot distinguish a legitimate request from a forged one based on cookies alone.

The attack works as follows: a victim is logged into bank.com, which sets a session cookie. The attacker lures them to evil.com, which contains an image tag or hidden form that fires a POST to bank.com/transfer. The browser sends the request with the victim's cookie, and the server processes it as legitimate.

Primary defenses:

**Synchronizer Token Pattern (Anti-CSRF Token):** The server generates a unique, unpredictable token per session (or per form), embeds it in the HTML form or JavaScript-accessible meta tag, and validates it on every state-changing request. The attacker cannot read the token due to the same-origin policy, so they cannot forge a valid request. This is the gold standard. Frameworks like Django, Rails, and Spring include this by default.

**SameSite Cookie Attribute:** Setting `SameSite=Strict` or `SameSite=Lax` on session cookies instructs the browser not to send them on cross-site requests. `Strict` blocks all cross-site sends; `Lax` blocks POST but allows safe top-level navigations. This is now the browser default for cookies without an explicit attribute in modern browsers. It is a strong second layer but not a complete replacement for token-based protection in all legacy environments.

**Double Submit Cookie:** The server sets a random value as both a cookie and requires it as a request parameter. Since the attacker cannot read cookies cross-origin, they cannot replicate the value in the parameter. Useful for stateless architectures.

**Origin / Referer Header Validation:** Check that the `Origin` or `Referer` header matches the expected domain. Less reliable as headers can be absent (Referer is blocked by some privacy settings), so this should be a secondary check.

**Custom Request Header:** APIs that require a custom header (e.g., `X-Requested-With: XMLHttpRequest`) exploit the fact that simple cross-site requests cannot set arbitrary headers. SPAs using JSON APIs with custom headers are naturally protected. However, this only works when the server enforces the header check.

In modern stack terms: Django's `CsrfViewMiddleware` handles token injection and validation. For REST APIs consumed by SPAs, `SameSite=Lax` plus CORS restrictions usually suffices. Always combine layers.

Question 5

What is XSS and how do you prevent it?

Accepted Answer

Cross-Site Scripting (XSS) is a code injection vulnerability where an attacker injects malicious scripts into content served to other users. Unlike CSRF, which abuses the browser's trust in a session, XSS abuses the victim's trust in a website — the script runs in the origin of the target site and has full access to its DOM, cookies, and localStorage.

There are three main types:

**Reflected XSS:** Malicious input is immediately echoed back in the HTTP response without sanitization. The payload travels in a URL parameter; the victim is tricked into clicking the link. Common in search pages and error messages.

**Stored XSS:** The payload is persisted in the database (e.g., a comment, profile bio) and rendered for all users who view that resource. Higher severity because it requires no victim-specific link.

**DOM-based XSS:** The vulnerability lives entirely in client-side JavaScript. The page reads from an attacker-controlled source (e.g., `location.hash`, `document.referrer`) and writes it to a dangerous sink (`innerHTML`, `eval`, `document.write`) without sanitization. The server never sees the payload.

Prevention:

**Context-aware output encoding:** The most important defense. HTML-encode untrusted data before inserting it into HTML context (`&` → `&`, `<` → `<`). Use attribute encoding for HTML attributes, JavaScript encoding for script contexts, and URL encoding for URLs. Never mix encoding schemes for the wrong context.

**Use safe APIs:** Prefer `textContent` over `innerHTML`. In React/Vue/Angular, the framework auto-escapes by default — never use `dangerouslySetInnerHTML` or `v-html` with untrusted input. Template engines like Jinja2 auto-escape by default; mark trusted HTML explicitly.

**Content Security Policy (CSP):** A response header (`Content-Security-Policy: default-src 'self'`) that instructs browsers to only execute scripts from allowed sources. A strict CSP with nonces or hashes and no `'unsafe-inline'` is a strong second layer. It does not replace encoding but limits attacker impact even if encoding is missed.

**Input validation:** Validate format and type on input (e.g., reject `<` in a name field), but do not rely on this as the primary defense — encoding at output is more reliable.

**HttpOnly cookies:** Prevent JavaScript from reading session cookies, limiting cookie theft even if XSS fires. Combine with Secure and SameSite flags.

In practice: Django templates auto-escape, React auto-escapes JSX, but both have escape hatches that developers misuse. Code review should flag any raw HTML insertion. A CSP header adds defense-in-depth.

Question 6

Explain the OAuth 2.0 Authorization Code Flow.

Accepted Answer

The OAuth 2.0 Authorization Code Flow is the recommended grant type for web applications where a server-side backend can securely hold a client secret. It allows users to grant a third-party application access to their resources on another service (like Google or GitHub) without sharing their password.

**Participants:**
- **Resource Owner**: the user
- **Client**: the application requesting access (your app)
- **Authorization Server**: issues tokens (e.g., Google's OAuth server)
- **Resource Server**: the API holding the user's data (e.g., Google Calendar API)

**Flow steps:**
1. **Authorization Request**: The client redirects the user's browser to the authorization server with: `response_type=code`, `client_id`, `redirect_uri`, `scope`, and a `state` parameter (random nonce for CSRF protection).

2. **User Consent**: The user authenticates with the authorization server and grants the requested scopes. The authorization server does NOT share the user's credentials with the client.

3. **Authorization Code**: The authorization server redirects back to `redirect_uri` with a short-lived `code` and the `state` parameter. The client verifies `state` matches the value from step 1.

4. **Token Exchange**: The client's **backend** makes a server-to-server POST to the authorization server's token endpoint with: `code`, `redirect_uri`, `client_id`, and `client_secret`. This happens server-side — the `client_secret` never touches the browser.

5. **Token Response**: The authorization server returns an `access_token` (short-lived, 1h typically) and optionally a `refresh_token` (long-lived). The access token is used to call the Resource Server's API.

6. **API Calls**: The client includes `Authorization: Bearer <access_token>` in requests to the Resource Server.

**Why the two-step code + token exchange?** The authorization code travels through the browser's redirect URL — it could be intercepted by browser history, logs, or referrer headers. By making the code short-lived and requiring the client secret for exchange, an intercepted code is useless without the secret, which never leaves the server.

**PKCE (Proof Key for Code Exchange)** extends this flow for public clients (SPAs, mobile apps) that cannot hold a client secret. The client generates a `code_verifier` (random string), sends its hash (`code_challenge`) with the authorization request, and sends the original `code_verifier` during token exchange. The authorization server verifies the match — preventing code interception attacks even without a client secret.

Question 7

What is the difference between symmetric and asymmetric encryption?

Accepted Answer

Symmetric and asymmetric encryption are the two fundamental paradigms of modern cryptography. They solve different problems and are almost always used together in production systems.

**Symmetric encryption** uses a single shared key for both encryption and decryption. The sender encrypts with the key; the recipient decrypts with the same key. Common algorithms: AES-128/256 (block cipher), ChaCha20 (stream cipher). Symmetric encryption is computationally fast — AES-NI hardware acceleration makes it suitable for encrypting gigabytes of data per second. The fundamental problem is **key distribution**: both parties must share the secret key before communicating, but transmitting the key over an insecure channel defeats the purpose of encryption.

**Asymmetric encryption** uses a mathematically linked key pair: a **public key** (shareable with anyone) and a **private key** (kept secret). Data encrypted with the public key can only be decrypted with the corresponding private key. Common algorithms: RSA-2048/4096, Elliptic Curve (ECDH, ECDSA). Asymmetric encryption solves the key distribution problem — anyone can encrypt a message using your public key; only you can decrypt it. However, it is computationally expensive: 100-1000x slower than symmetric encryption for bulk data. RSA is also limited in the message size it can encrypt directly.

**How they combine in practice (hybrid encryption):**
TLS uses both. During the TLS handshake, asymmetric cryptography (ECDH key exchange) is used to securely establish a shared symmetric session key. All subsequent data is encrypted with that symmetric key (AES-GCM). You get the key distribution benefit of asymmetric crypto and the performance of symmetric crypto. This is the pattern used by HTTPS, Signal, SSH, and virtually every secure communication protocol.

**Digital signatures** are a distinct use of asymmetric keys: you sign data with your **private key**; anyone can verify the signature with your **public key**. This provides authenticity and non-repudiation — only you could have created the signature.

**Key length comparisons**: AES-256 symmetric key ≈ RSA-3072 asymmetric in terms of security level. Asymmetric keys must be much longer because their security relies on mathematical problems (integer factorization, discrete log) that are harder but not as hard as brute-forcing a symmetric key.

Security Interview Questions — What Senior Engineers Need to Know

All 7 Questions

How to Prepare

Related Topics

Test Your Knowledge