Cybersecurity interview questions

How to approach thisThe OWASP Top 10 lists the most critical web application security risks. Current top entries: Broken Access Control, Cryptographic Failures, Injection, Insecure Design, Security Misconfiguration. The most impactful tend to be Injection (SQL, XSS) and Broken Access Control (IDOR, privilege escalation) because they directly lead to data breaches. Know mitigations for each.

How to approach thisSQL injection occurs when user input is concatenated directly into a SQL query, allowing attackers to modify the query logic. Prevention: always use parameterized queries (prepared statements), never string-concatenate user input into SQL, use an ORM that parameterizes by default, validate and sanitize input, and apply least-privilege database permissions.

How to approach thisAuthentication verifies who you are (login with credentials). Authorization determines what you can do (access control). Authentication happens first; authorization depends on it. Example: logging in proves you are user X (authentication); checking if user X can delete a post is authorization. Implement both at every API endpoint, not just at the front door.

How to approach thisThe TLS handshake: client sends supported cipher suites, server responds with its certificate and chosen cipher. Client verifies the certificate chain against trusted CAs. They exchange keys using asymmetric encryption (RSA or ECDHE) to establish a shared session key. All subsequent data is encrypted with the session key (symmetric encryption). TLS 1.3 reduces the handshake to 1 round trip.

How to approach thisXSS injects malicious JavaScript into web pages. Types: Stored XSS (malicious script saved in the database, served to all visitors), Reflected XSS (script in URL parameter, reflected in the response), DOM-based XSS (client-side JavaScript processes untrusted data). Prevent with: output encoding, Content Security Policy headers, and using frameworks that auto-escape (React, Angular).

How to approach thisNever store passwords in plain text. Hash with a slow, salted algorithm: bcrypt, scrypt, or Argon2 (not MD5 or SHA-256 which are too fast). Use a unique random salt per password (most libraries handle this automatically). Set a high work factor (bcrypt cost 12+). For additional security, pepper the hash with a server-side secret stored outside the database.

How to approach thisCross-Site Request Forgery tricks a logged-in user into making unintended requests (e.g., transferring money). The attack works because the browser automatically includes cookies with requests. Prevention: use anti-CSRF tokens (unique per session, verified server-side), SameSite cookie attribute (Lax or Strict), check the Origin/Referer header, and require re-authentication for sensitive actions.

How to approach thisEvery user, service, and process should have only the minimum permissions needed to perform its function. Apply it to: database users (read-only for reporting services), IAM roles (specific actions on specific resources), file permissions, network access (firewall rules), and API keys (scoped to required endpoints). Audit permissions regularly and revoke unused access.

How to approach thisSign tokens with a strong algorithm (RS256 or ES256, not HS256 with a weak secret). Set short expiration times (15 minutes for access tokens). Use refresh tokens (stored securely, rotated on use) for re-authentication. Include only necessary claims (user ID, role) not sensitive data. Validate all claims on every request. Implement token revocation for logout and account compromise.

How to approach thisZero trust assumes no implicit trust based on network location. Every request is verified regardless of whether it comes from inside or outside the network. Principles: verify explicitly (authenticate and authorize every request), least privilege access, assume breach (minimize blast radius). Implement with: strong identity verification, micro-segmentation, continuous monitoring, and encrypted communications everywhere.

How to approach thisImmediate: contain the breach (revoke compromised credentials, isolate affected systems). Investigate: determine the scope (what data, how many users, attack vector). Eradicate: patch the vulnerability, remove attacker access. Notify: inform affected users and regulatory bodies within required timeframes (GDPR: 72 hours). Recover: restore services. Post-mortem: document lessons learned and implement preventive measures.

How to approach thisSymmetric encryption uses the same key to encrypt and decrypt (AES, ChaCha20). It is fast but requires secure key exchange. Asymmetric encryption uses a public key to encrypt and a private key to decrypt (RSA, ECC). It is slower but solves the key exchange problem. In practice, TLS uses asymmetric encryption to exchange a symmetric session key, then uses symmetric encryption for data.