Security Interview Questions (with real STAR answers)

A list from OWASP of the most critical web application security risks. It includes broken access control, injection, cryptographic failures, security misconfiguration, vulnerable and outdated components, authentication failures, and server-side request forgery (SSRF). Be ready to explain a few and how to prevent them.

Use parameterized queries or prepared statements so user input is always treated as data, never as SQL. ORMs do this by default. Add input validation and run the database user with the least privileges it needs. Never build SQL with string concatenation.

XSS is when an attacker gets their JavaScript to run in another user's browser. It can be stored (saved in the database), reflected (from the URL), or DOM-based. Prevent it by encoding output for the context it appears in, using frameworks that escape by default, sanitizing any HTML you must allow, and adding a Content Security Policy.

Cross-site request forgery tricks a logged-in user's browser into sending a request to your site, because the browser attaches cookies automatically. Prevent it with SameSite cookies (Lax or Strict), anti-CSRF tokens on state-changing requests, and by never changing data on GET requests.

Encoding (for example Base64) changes the format and anyone can reverse it - it is not security. Encryption (for example AES) is reversible with a key and protects confidentiality. Hashing (for example SHA-256) is one-way and is used for integrity checks; for passwords, use a slow password hashing function.

Never in plaintext or with fast hashes like MD5 or SHA-1. Use a slow, salted password hashing algorithm - Argon2id, bcrypt, or scrypt - with a cost factor high enough to slow down brute force. The salt is unique per password and is stored with the hash.

Symmetric encryption (AES) uses one shared key to encrypt and decrypt, and it is fast. Asymmetric encryption (RSA, elliptic curve) uses a public key and a private key, and is used for key exchange and digital signatures. TLS uses asymmetric cryptography to agree on a symmetric key, then encrypts the data with it.

The client and server agree on the TLS version and cipher suite, the server sends its certificate, and the client checks that it is valid and issued by a trusted certificate authority for that hostname. They then do a key exchange (usually ECDHE) to create shared session keys, and all further data is encrypted with them.

Authentication checks who you are (password, token, MFA). Authorization checks what you are allowed to do. Many serious bugs are authorization bugs, such as IDOR, where the user is logged in but can reach data that belongs to someone else.

Server-side request forgery is when an attacker makes your server send requests to a URL they choose, often internal services or the cloud metadata endpoint (169.254.169.254). Prevent it with an allowlist of hosts, by resolving the hostname and blocking private and link-local IP ranges, by not following redirects blindly, and by using IMDSv2 on AWS.

Accepting the 'none' algorithm or any algorithm the token claims, using a weak or shared signing secret, not checking expiry, putting sensitive data in the payload (it is only encoded, not encrypted), and storing tokens in localStorage where XSS can read them. Pin the algorithm and validate exp, iss, and aud.

Confidentiality (only authorized people can read data), Integrity (data is not changed without authorization), and Availability (systems and data are there when needed). Most security controls protect one or more of these three.

Treat the key as compromised. Deactivate and rotate it right away, then check CloudTrail for activity from that key and look for new users, roles, or resources. Remove the key from git history with git filter-repo and force-push, but assume it was already copied. Then add secret scanning such as gitleaks in pre-commit hooks and CI.

Confirm that the vulnerable version is really in use and whether the vulnerable code path is reachable. Upgrade to a patched version (or apply a workaround if none exists), run the tests, and deploy. Use tools such as Trivy, pip-audit, or npm audit in CI so new vulnerable versions are caught before release.

Expect behavioral questions (tell me about a time you...), technical questions on OWASP vulnerabilities, authentication, cryptography, and cloud permissions, and incident scenarios such as a leaked key. Some companies also ask you to review code for vulnerabilities. The questions on this page cover all of these.

Use STAR: Situation, Task, Action, Result. Keep it concrete - a specific incident, what you owned, what you did, and the result. The answers above are all structured this way.