Question 1

What is OWASP Top 10 and how should you use that list?

Accepted Answer

OWASP Top 10 is a public ranking of the most common risk categories of web applications, updated periodically from real data. It is not an exhaustive checklist but a starting point for team training and prioritization. Categories include Broken Access Control, cryptographic failures, injection, insecure design, misconfiguration and vulnerable components. There is also a separate OWASP API Security Top 10, shifted toward authorization and endpoint inventory.

Question 2

How does authentication differ from authorization?

Accepted Answer

Authentication answers who you are: checking a password, a code from an app, a passkey. Authorization answers what you are allowed to do: whether you can read this document or delete a user. One does not work without the other: a user can be genuine but have no right to the action. Authorization is checked on the server for every request, not just by hiding a button in the interface.

Question 3

What is SQL injection and how do you defend against it?

Accepted Answer

SQL injection happens when user input is inserted into the query text and an attacker changes its structure, for example by adding ' OR 1=1 --. The main defense is parameterized queries, where values are passed separately from the SQL text and are never interpreted as code. An ORM helps, but raw queries and dynamic column names or ORDER BY remain a risk. Also: least privilege for the database user and input validation.

Question 4

What is XSS and what kinds does it have?

Accepted Answer

Cross-Site Scripting is the execution of someone else's JavaScript in the context of your site in the victim's browser. Stored XSS: malicious code is saved on the server, for example in a comment, and runs for everyone who opens it. Reflected: the code arrives in a request parameter and is immediately echoed in the response. DOM-based: a vulnerability in client code that writes untrusted data into the DOM, for example through innerHTML. The main defense is context-aware output escaping, safe APIs such as textContent, and CSP as a second line.

Question 5

What is CSRF and how do you defend against it?

Accepted Answer

Cross-Site Request Forgery makes the browser of a logged-in user send a request to your site from another site, and the browser adds the cookie itself. Defenses: a CSRF token that a malicious site cannot read, the cookie attribute SameSite=Lax or Strict, and checking the Origin and Referer headers. State-changing actions are not done through GET. An API that authenticates with an Authorization header rather than a cookie does not suffer from CSRF, because the browser does not add such a header automatically.

Question 6

How should user passwords be stored correctly?

Accepted Answer

A password is never stored in plain text and never encrypted reversibly. What is stored is the result of a slow salted hash function: argon2id, bcrypt or scrypt. The salt is unique per password and prevents the use of precomputed tables. Slowness and memory cost make brute force expensive even after a database leak. Fast hashes like SHA-256 or MD5 are not suitable for passwords.

Question 7

What does HTTPS give you and how does TLS work in broad terms?

Accepted Answer

HTTPS is HTTP over TLS. It gives three things: traffic encryption, integrity (data was not altered in transit) and server authenticity via a certificate. During the handshake the client verifies a certificate issued by a trusted authority, the parties agree on keys, and then data is encrypted symmetrically. Without HTTPS, passwords and cookies are visible on the network and a page can be changed on the way. The HSTS header tells the browser to always use HTTPS for the site.

Question 8

What is CORS and does it protect an API from attackers?

Accepted Answer

The same-origin policy does not let a script from one origin read responses from another. CORS is the mechanism by which a server explicitly allows the browser to do such reading for specified origins via headers such as Access-Control-Allow-Origin. It protects the user in the browser, not the server: curl or any script outside a browser ignores CORS. So API authorization cannot be built on CORS. Combining * with sending cookies is forbidden, and reflecting any Origin back is dangerous.

Question 9

What is a JWT, what does it consist of, and is it encrypted?

Accepted Answer

A JWT is a compact token of three parts: header, payload and signature, encoded in base64url. The payload is not encrypted, anyone can read it, so sensitive data is not put there. The signature guarantees the token was not changed and was issued by someone who holds the key. A valid token works until exp expires, and revoking it earlier is hard, so access tokens are made short-lived. The token is sent in Authorization: Bearer.

Question 10

Which security headers should a web application send?

Accepted Answer

Strict-Transport-Security enforces HTTPS. Content-Security-Policy restricts script sources and reduces XSS impact. X-Content-Type-Options: nosniff forbids the browser from guessing content type. frame-ancestors in CSP (or X-Frame-Options) protects against clickjacking. Referrer-Policy limits URL leakage, and Permissions-Policy turns off unneeded browser features. These are layers of defense that complement but do not replace secure code.

Question 11

Which items of OWASP API Security Top 10 2023 do you see most often in a backend API, and how does this list differ from the classic Top 10?

Accepted Answer

The most frequent: API1 BOLA, where an object is looked up by an id from the URL without an ownership check; API3 BOPLA, extra fields in the response or mass assignment in the request body; API5 BFLA, an admin function without a role check, often on another method or API version; API4 and API6, no limits and no protection of business flows from bots. The API list is shifted toward authorization and endpoint inventory rather than XSS or rendering, because an API has no browser UI.

Question 12

A pentest found that when updating a profile a regular user became admin, and the response shows a password hash. What is this vulnerability and how do you fix it?

Accepted Answer

This is BOPLA: mass assignment on input and excessive fields on output. The controller copies the request body into an entity without a whitelist, and the client adds role: "admin", and on the response the whole entity is returned. Fix: separate input and output DTOs listing only allowed fields, validation that rejects unknown properties, and explicit response construction instead of serializing the model. Fields that change privileges are allowed only on a dedicated admin endpoint.

Question 13

A user changed the id in the URL /orders/123 to /orders/124 and saw someone else's order. What is this and how do you fix it systematically?

Accepted Answer

This is IDOR, in OWASP API terms BOLA: the server checks that the user is logged in, but not that the object belongs to them. Fix: check the owner or permission on every object access, or better build it into the database query (WHERE id = ? AND owner_id = ?) or a common access layer, so you do not rely on a developer's memory. Unpredictable UUIDs instead of sequential ids make enumeration harder but do not replace permission checks. For regressions, write tests that try other users' ids.

Question 14

A colleague says an ORM protects against SQL injection. When is that not true?

Accepted Answer

An ORM protects only when values go in as parameters. If in a query builder or raw query a value is interpolated with a template string (where(name = '${name}')), that is an ordinary injection. The same goes for column names and the direction in ORDER BY that come from the client: they cannot be passed as parameters, so they are checked against a list of allowed values. In Prisma, $queryRawUnsafe is dangerous, while the tagged $queryRaw parameterizes interpolations automatically. Reviewing every raw query is mandatory.

Question 15

A login on Express and Mongoose: an attacker gets in as admin without knowing the password. What request body could he have sent?

Accepted Answer

This is NoSQL injection through operators. If the code passes the body straight into the query User.findOne({ email, password }), the attacker sends JSON { "email": "admin@x.com", "password": { "$ne": null } }, and the condition becomes true for any password. Defense: validate the type of input fields (a string, not an object) with a schema such as zod or class-validator, do not compare passwords through a database query but fetch the user by email and verify the hash in code, and if needed sanitize keys containing $.

Question 16

A backend serves comments for an SPA. After a stored XSS incident, the frontend says it is the backend's problem and the backend says it is the frontend's. Who is right?

Accepted Answer

Responsibility is shared. The main defense is output escaping at the place of rendering, that is on the frontend: React escapes text by default, while dangerouslySetInnerHTML or innerHTML create a hole. The backend is responsible for validation, sanitizing the allowed HTML with a proven library if HTML is needed, the correct Content-Type and security headers, CSP and HttpOnly cookies, so session theft is harder. One layer is not enough, you need defense in depth.

Question 17

What flags should a session cookie have and what does each do?

Accepted Answer

HttpOnly forbids reading the cookie from JavaScript, which makes stealing it through XSS harder. Secure allows sending it only over HTTPS. SameSite=Lax or Strict does not attach the cookie to cross-site requests, which lowers CSRF risk. Path and Domain limit the scope: with a broad Domain the cookie is available to all subdomains, including less protected ones. The __Host- name prefix requires Secure, path / and no Domain, so the cookie is strictly bound to one host.

Question 18

A user provides a webhook URL, the service sends a request to it and shows the response. What vulnerability is this and how do you close it?

Accepted Answer

This is SSRF: the server can be made to reach internal addresses such as http://localhost, private networks or the cloud metadata address 169.254.169.254, and hand back the result. Defense: allow only https and an allow-list of hosts where possible; resolve DNS yourself and reject private, loopback and link-local addresses; do not follow redirects after the check; limit time and response size; keep such requests in an isolated network segment with no access to internal services. Do not show the response to the user raw.

Question 19

An endpoint accepts a zip, extracts the files and serves them by a link from the same domain. What are the risks?

Accepted Answer

Zip slip: names like ../../etc/x write files outside the target directory, so the path after normalization must stay within the folder. Zip bomb: a small archive expands into gigabytes, so you limit total size, file count and depth. Serving uploaded files from the main domain leads to stored XSS (HTML or SVG), so they are served from a separate domain or with Content-Disposition: attachment and X-Content-Type-Options: nosniff. The file type is checked by content, not by extension, and uploaded files are not executed.

Question 20

How do you choose argon2id or bcrypt parameters for login, and what is a pepper?

Accepted Answer

Parameters are tuned so that one check takes about 100 to 500 ms on your hardware: argon2id with parameters from OWASP recommendations, or bcrypt with a cost of at least 10 to 12. They are raised over time and the password is rehashed on the next successful login. A pepper is a secret shared by the whole system, added to the password or hash and stored separately from the database, for example in a secrets manager. It helps when only the database leaked. A heavy hash also needs DoS protection: limits on login rate and concurrency.

Question 21

By what paths do secrets leak from a service, and is it enough to delete .env from the repo in the next commit?

Accepted Answer

It is not enough: the file stays in git history, so the key is treated as compromised and rotated. Typical leak paths: git history, Docker image layers, environment variables in logs and in docker inspect, error messages with a connection string, CI logs, artifacts and client bundles that got variables without a prefix check. Defense: secret scanners in pre-commit and CI, a secrets manager, least-privilege keys with a short lifetime, masking in logs, separate keys per environment.

Question 22

TLS is terminated at Nginx, and the app listens on localhost behind it. What should you pay attention to in the configuration?

Accepted Answer

Allow only TLS 1.2 and 1.3 with modern ciphers, enable HSTS, an HTTP to HTTPS redirect and automatic certificate renewal (Let's Encrypt). The app must know the original request was secure: Nginx passes X-Forwarded-Proto and X-Forwarded-For, and the app trusts these headers only from its own proxy, otherwise a client can forge them. Otherwise Secure cookies and absolute links will misbehave. The hop between Nginx and the app on the same host is protected by isolation, but across a separate network you need encryption.

Question 23

What does HSTS do and what are the risks of includeSubDomains and preload?

Accepted Answer

The Strict-Transport-Security header tells the browser to use only HTTPS for the domain for max-age, which closes downgrade attacks and SSL stripping. includeSubDomains extends the rule to all subdomains, so a subdomain without HTTPS will stop opening. preload adds the domain to the browsers' built-in list, and undoing that later takes a very long time. So you enable it gradually: first a small max-age after checking all subdomains, and only then increase it.

Question 24

In a multi-tenant SaaS on one database, customer A saw customer B's invoices. Where does the mistake usually hide and how do you make isolation reliable?

Accepted Answer

Typical holes: a query without a tenant_id condition, lookup by id without a tenant check, background jobs or cache without a tenant key, aggregations and exports. Relying on a developer to remember WHERE tenant_id is unreliable. Isolation is built into the access layer (a mandatory filter in the repository or ORM scope), the tenant comes from the authenticated context rather than a request parameter, and at the database level you enable Row Level Security as the last line. Add tests with two tenants that check cross-tenant access.

Question 25

Partners integrate with your API through keys. How do you design the key format, storage, verification and rotation?

Accepted Answer

The key is generated by a cryptographic generator, long enough, with a prefix that identifies the type and lets scanners find leaks. It is shown once, and the database stores only a hash (a fast SHA-256 is enough because the key has high entropy) and a short public prefix for lookup. For each key you set scopes and limits, an expiry and an owner. Rotation: two keys can be active at once so the client switches without downtime. Usage is logged and suspicious keys are revoked immediately.

Question 26

A reporting service pulls data from your API hourly without a user. Which OAuth2 flow do you use?

Accepted Answer

Client credentials: the service as a client authenticates to the authorization server with its client_id and secret (or better a certificate or signed assertion) and receives a short-lived access token with the needed scopes. There is no user here, the token represents the service itself. The token is cached until it expires rather than requested on every call. The client secret is stored as a secret, rotated, and granted minimal scopes.

Question 27

The authorization code flow has state, nonce and code_verifier. What does each one protect against?

Accepted Answer

state binds the response to the request that this very user initiated and protects the redirect endpoint from CSRF. nonce is embedded in the id token and checked by the client, which protects against replay of the id token. code_verifier in PKCE proves that the code exchange is done by the same client that started the flow: an intercepted code without the verifier is useless. PKCE is now recommended for all clients, not only public ones.

Question 28

A user pressed 'Log out' in an app that signs in through Keycloak. What should happen on the client, in the backend and in the provider?

Accepted Answer

On the client you delete the local session and tokens from memory or cookies. In the provider you end the SSO session through the end-session endpoint (RP-initiated logout), otherwise the next login will pass without a password. Refresh tokens are revoked through the revocation endpoint. A JWT access token stays valid until exp, so its lifetime is kept short, and for critical operations revocation is checked through introspection or a denylist. You can also use back-channel logout so the provider notifies all applications.

Question 29

An API accepts tokens from a shared realm, and a pentest got into the API with an id token. Why is this a problem and how do you fix it?

Accepted Answer

An id token is meant for the client to learn who logged in, not for calling an API. Its aud is the client, not your API, so an API that checks only the signature and iss accepts a token issued for any application in the realm. Fix: the API checks aud (or azp and scope) against its own identifier, accepts only access tokens of the right type, and tells them apart by claims such as typ. Use a separate audience per resource server.

Question 30

The security team found tokens, passwords and password reset links in the logs. How do you fix this systematically?

Accepted Answer

Log selectively, not 'the whole request and response'. Set up masking at the logger level by a list of sensitive keys (password, authorization, token, cookie) and never log the bodies of authentication requests. Reset links and tokens in URLs end up in proxy logs, so make them short-lived and single-use. Add tests that check no secrets appear in logs, and restrict access to the logs themselves and their retention. Whatever already got into logs is considered compromised and rotated.

Web security interview questions and answers

Junior questions

1. What is OWASP Top 10 and how should you use that list?

2. How does authentication differ from authorization?

3. What is SQL injection and how do you defend against it?

4. What is XSS and what kinds does it have?

5. What is CSRF and how do you defend against it?

6. How should user passwords be stored correctly?

7. What does HTTPS give you and how does TLS work in broad terms?

8. What is CORS and does it protect an API from attackers?

9. What is a JWT, what does it consist of, and is it encrypted?

10. Which security headers should a web application send?

Middle questions

1. Which items of OWASP API Security Top 10 2023 do you see most often in a backend API, and how does this list differ from the classic Top 10?

2. A pentest found that when updating a profile a regular user became admin, and the response shows a password hash. What is this vulnerability and how do you fix it?

3. A user changed the id in the URL /orders/123 to /orders/124 and saw someone else's order. What is this and how do you fix it systematically?

4. A colleague says an ORM protects against SQL injection. When is that not true?

5. A login on Express and Mongoose: an attacker gets in as admin without knowing the password. What request body could he have sent?

6. A backend serves comments for an SPA. After a stored XSS incident, the frontend says it is the backend's problem and the backend says it is the frontend's. Who is right?

7. What flags should a session cookie have and what does each do?

8. A user provides a webhook URL, the service sends a request to it and shows the response. What vulnerability is this and how do you close it?

9. An endpoint accepts a zip, extracts the files and serves them by a link from the same domain. What are the risks?

10. How do you choose argon2id or bcrypt parameters for login, and what is a pepper?

11. By what paths do secrets leak from a service, and is it enough to delete .env from the repo in the next commit?

12. TLS is terminated at Nginx, and the app listens on localhost behind it. What should you pay attention to in the configuration?

13. What does HSTS do and what are the risks of includeSubDomains and preload?

14. In a multi-tenant SaaS on one database, customer A saw customer B's invoices. Where does the mistake usually hide and how do you make isolation reliable?

15. Partners integrate with your API through keys. How do you design the key format, storage, verification and rotation?

16. A reporting service pulls data from your API hourly without a user. Which OAuth2 flow do you use?

17. The authorization code flow has state, nonce and code_verifier. What does each one protect against?

18. A user pressed 'Log out' in an app that signs in through Keycloak. What should happen on the client, in the backend and in the provider?

19. An API accepts tokens from a shared realm, and a pentest got into the API with an id token. Why is this a problem and how do you fix it?

20. The security team found tokens, passwords and password reset links in the logs. How do you fix this systematically?

21. How do you protect login and sensitive endpoints from brute force and abuse?

22. How are passkeys better than passwords, and what MFA methods exist?

Senior questions

1. Design a Content-Security-Policy for a React admin panel. Why is unsafe-inline for scripts dangerous?

2. A colleague proposes removing CSRF tokens because browsers now default to SameSite=Lax. When is he right and when not?

3. Code resolves a domain and checks the IP is not private, then makes the request. Is that enough against SSRF?

4. A service generates image previews by calling ImageMagick through exec with a user-provided file name. What injections are there, and is escaping quotes enough?

5. After another service's database leak, your login received 2 million attempts from 40 thousand IPs, 1 to 3 attempts per account. What do you do?

6. Compare RBAC, ABAC and ReBAC on the example of a document system: a user sees their own documents, their team's documents and shared ones.

7. You enabled Row Level Security to isolate tenants. It works in tests, but in production under load clients occasionally see foreign data. What do you suspect?

8. What are typical mistakes in JWT verification on a backend, according to RFC 8725 and practice?

9. Where should an SPA keep tokens? A colleague stores access and refresh tokens in localStorage because HttpOnly cookies are 'inconvenient'.

10. After introducing refresh token rotation with reuse detection, users with two tabs are massively logged out. Why?

11. The billing service trusts the X-User-Id header set by the gateway. Through SSRF in another service an attacker called billing directly. What went wrong?

12. What is mTLS and when should you use it between services?

13. npm audit shows 47 vulnerabilities, the team has ignored them for a long time, and the news is full of attacks through packages. What do you do?

14. On Friday evening you learn that the JWT signing secret has been in a contractor's public GitHub repo for three days. What do you do?

Train these questions

Answer out loud and get graded

Other topics

Explore the platform

3. A user changed the id in the URL `/orders/123` to `/orders/124` and saw someone else's order. What is this and how do you fix it systematically?

11. By what paths do secrets leak from a service, and is it enough to delete `.env` from the repo in the next commit?

13. What does HSTS do and what are the risks of `includeSubDomains` and `preload`?

17. The authorization code flow has `state`, `nonce` and `code_verifier`. What does each one protect against?

1. Design a Content-Security-Policy for a React admin panel. Why is `unsafe-inline` for scripts dangerous?

2. A colleague proposes removing CSRF tokens because browsers now default to `SameSite=Lax`. When is he right and when not?

4. A service generates image previews by calling ImageMagick through `exec` with a user-provided file name. What injections are there, and is escaping quotes enough?

9. Where should an SPA keep tokens? A colleague stores access and refresh tokens in `localStorage` because `HttpOnly` cookies are 'inconvenient'.

11. The billing service trusts the `X-User-Id` header set by the gateway. Through SSRF in another service an attacker called billing directly. What went wrong?

13. `npm audit` shows 47 vulnerabilities, the team has ignored them for a long time, and the news is full of attacks through packages. What do you do?