Web, Security & Networking interview questions and answers

Question 1

What happens when you type a URL and press enter?

Accepted Answer

Answer, in order: 1. DNS lookup. The browser turns the domain name (example.com) into an IP address, checking its cache, then the OS, then a DNS resolver. 2. TCP connection. The browser opens a TCP connection to that IP on port 443 (a three-way handshake: SYN, SYN-ACK, ACK). 3. TLS handshake. For HTTPS, the browser and server agree on encryption keys and the server proves its identity with a certificate. 4. HTTP request. The browser sends GET / with headers (Host, cookies, Accept). 5. Server responds. It returns an HTTP status and the HTML. 6. Render. The browser parses the HTML, requests CSS, JS, and images (more requests), builds the page, runs the JavaScript, and paints it. Analogy: posting a letter: look up the address (DNS), establish a phone line to confirm they are there (TCP), agree a private code (TLS), then actually send the message (HTTP) and act on the reply (render). In an interview: DNS resolves the name to an IP, TCP opens a connection, TLS negotiates encryption and verifies the certificate, then an HTTP request goes out, the server responds with HTML, and the browser fetches sub-resources and renders.

Question 2

What is DNS and how does it work?

Accepted Answer

Answer: DNS (Domain Name System) is the internet's phone book. It translates human names like example.com into IP addresses like 93.184.216.34, because computers route by IP, not by name. A lookup walks a hierarchy, usually with caching at every step so most lookups are instant: 1. Browser cache, then OS cache. 2. A recursive resolver (your ISP's or a public one like 8.8.8.8). 3. The resolver asks a root server, which points to the .com nameservers, which point to example.com's nameservers, which return the final IP. Answers are cached for a time set by the record's TTL. Analogy: asking directory enquiries. You do not memorise phone numbers, you ask for them by name, and the operator remembers common ones so the next request is faster. In an interview: DNS maps names to IP addresses through a cached hierarchy: browser, OS, recursive resolver, then root, TLD, and the domain's own nameservers. Results are cached for the record's TTL.

Question 3

What is HTTP, and what are the main methods?

Accepted Answer

Answer: HTTP is the request-response protocol the web runs on. A client sends a request (method, path, headers, optional body); the server sends a response (status code, headers, optional body). It is stateless: each request stands alone, so state is carried in cookies or tokens. The main methods: GET: read a resource. No body, safe (no side effects), cacheable. POST: create a resource or run an action. Has a body, not idempotent. PUT: replace a resource entirely. Idempotent. PATCH: update part of a resource. DELETE: remove a resource. Idempotent. Analogy: ordering at a counter. GET is 'show me the menu', POST is 'place this new order', PUT is 'replace my whole order with this', PATCH is 'just change the drink', DELETE is 'cancel my order'. In an interview: HTTP is a stateless request-response protocol. GET reads, POST creates or acts, PUT replaces, PATCH partially updates, DELETE removes. GET is safe; GET, PUT, and DELETE are idempotent.

Question 4

What do the HTTP status code ranges mean?

Accepted Answer

Answer: The first digit tells you the category. 1xx informational (rare). 2xx success. 3xx redirection. 4xx the client did something wrong. 5xx the server failed. The ones you must know: 200 OK, 201 Created, 204 No Content, 301/302 redirect, 304 Not Modified (cache), 400 Bad Request, 401 Unauthorized (not logged in), 403 Forbidden (logged in but not allowed), 404 Not Found, 409 Conflict, 422 Unprocessable, 429 Too Many Requests, 500 Internal Server Error, 502/503 upstream or unavailable. Analogy: 4xx means 'you messed up', 5xx means 'we messed up'. That one distinction resolves most debates about whose fault an error is. In an interview: First digit is the category: 2xx success, 3xx redirect, 4xx client error, 5xx server error. Key nuance: 401 means not authenticated, 403 means authenticated but not allowed.

Question 5

What makes an API RESTful?

Accepted Answer

Answer: REST is a style, not a standard. An API is RESTful when it: - Models things as resources with URLs (/books, /books/42), using nouns not verbs. - Uses HTTP methods for the action (GET to read, POST to create, and so on) instead of putting the verb in the URL (/getBook). - Uses HTTP status codes to signal the outcome. - Is stateless: every request carries everything the server needs (auth token, etc.); the server keeps no session for the client. - Returns a consistent representation, usually JSON, and supports things like pagination and filtering with query parameters. The strict definition also requires HATEOAS (responses link to related actions), but most 'REST' APIs in practice skip that. Analogy: a well-organised building: rooms are numbered (resources have URLs), and you interact with each room the same standard way (HTTP methods), rather than every room needing its own custom instructions. In an interview: Resources as noun URLs, HTTP methods for actions, status codes for outcomes, stateless requests, and a consistent JSON representation with pagination and filtering. HATEOAS is the strict extra that most APIs skip.

Question 6

What is the difference between PUT and PATCH, and what does idempotent mean?

Accepted Answer

Answer: PUT replaces the entire resource with what you send. If you leave a field out, it is set to empty or default. PUT is idempotent: sending the same PUT ten times leaves the resource in the same state as sending it once. PATCH updates only the fields you send and leaves the rest alone. PATCH is not guaranteed to be idempotent (for example a PATCH that says 'add 1 to the count' changes the result each time). Idempotent means: making the same request multiple times has the same effect as making it once. This matters for retries: a client can safely retry an idempotent request after a network timeout without risking a double effect. GET, PUT, and DELETE are idempotent; POST and (in general) PATCH are not. Analogy: PUT is 'here is the finished document, replace the old one'. PATCH is 'in the existing document, change line 3'. Idempotent means pressing the button twice does not do the thing twice. In an interview: PUT replaces the whole resource and is idempotent. PATCH updates part of it and generally is not. Idempotent means repeating the request has the same effect as doing it once, which is what makes retries safe.

Question 7

What is CORS and why does it block requests?

Accepted Answer

Answer: CORS (Cross-Origin Resource Sharing) is a browser security rule. By default, JavaScript on site A cannot read responses from site B (a different origin: different scheme, host, or port). This is the same-origin policy, and it stops a malicious page from quietly reading your bank's API using your logged-in cookies. CORS is the controlled way to allow it. The server at B must send headers like Access-Control-Allow-Origin: https://a.com to opt in. For some requests the browser first sends a 'preflight' OPTIONS request to check. Key point: CORS is enforced by the browser, not the server. A blocked request often still reached the server; the browser just refuses to hand the response to your JavaScript. Server-to-server calls are not affected. Analogy: a bouncer (the browser) who will not let you carry messages between two clubs unless the second club has put your name on an approved list. In an interview: CORS is the browser's same-origin protection plus a server opt-in. The server sends Access-Control-Allow-Origin headers to permit a cross-origin page to read its responses. It is browser-enforced, so a blocked call may still have hit the server.

Question 8

What is the difference between GET and POST?

Accepted Answer

Answer: GET asks for data. Its parameters go in the URL as a query string (?q=shoes&page=2), it has no body, it is safe (no server-side changes), idempotent, cacheable, and can be bookmarked and appear in browser history and server logs. POST sends data to create something or trigger an action. Its parameters go in the request body, so they are not in the URL, it is not safe (it changes state), not idempotent (submitting twice creates two things), and not cached by default. Because GET parameters sit in the URL, never put passwords or sensitive data in a GET request. Use POST (or PUT/PATCH) for anything that changes data. Analogy: GET is reading a notice on a board, POST is filling in a form and posting it into the box. One looks, the other changes something. In an interview: GET reads data with parameters in the URL: safe, idempotent, cacheable, bookmarkable. POST sends data in the body to change state: not safe, not idempotent, not cached. Sensitive or state-changing operations use POST.

Question 9

What is the TCP/IP model and what are its layers?

Accepted Answer

Answer: TCP/IP is the layered model that describes how internet communication is organised. Each layer does one job and talks only to the layers next to it. 1. Link layer: moves bits between two directly connected machines (Ethernet, Wi-Fi). 2. Internet layer: routes packets across networks using IP addresses (IP). It is best-effort: packets may be lost, duplicated, or arrive out of order. 3. Transport layer: end-to-end delivery between programs, using port numbers. TCP adds reliability and ordering; UDP does not. 4. Application layer: the protocol your app speaks (HTTP, DNS, SMTP), carried on top of transport. The older OSI model has 7 layers but the 4-layer TCP/IP view is what people mean in practice. Analogy: posting a parcel through a courier network: the van between two depots (link), the routing plan across the country (internet), the promise that it arrives complete and in order (transport), and the letter inside (application). In an interview: Four layers: link (direct machine-to-machine), internet (IP routing, best-effort), transport (TCP or UDP, end-to-end via ports), application (HTTP, DNS, and so on). OSI's seven layers map onto this.

Question 10

What is the difference between TCP and UDP?

Accepted Answer

Answer: TCP is connection-based and reliable. It does a handshake to set up a connection, numbers every byte, re-sends anything lost, delivers data in order, and controls its sending rate to avoid congestion. The cost is latency and overhead. Used by HTTP, email, file transfer, anything where completeness matters. UDP is connectionless and unreliable. It just fires packets off with no handshake, no re-sending, no ordering. It is fast and low-overhead. Used by video calls, live streaming, gaming, and DNS, where a late packet is worse than a missing one. Rule of thumb: TCP when you need every byte, UDP when you need it now. Analogy: TCP is registered post with tracking and re-delivery. UDP is shouting across a room: fast, but if someone does not hear a word, it is gone. In an interview: TCP is connection-based, reliable, ordered, and rate-controlled, for when every byte matters. UDP is connectionless and unreliable but fast and lean, for real-time media, games, and DNS. Every byte versus right now.

Question 11

What is HTTPS, and what does TLS actually do?

Accepted Answer

Answer: HTTPS is HTTP running inside a TLS-encrypted connection. TLS (Transport Layer Security, the successor to SSL) provides three things: 1. Encryption: nobody on the network path can read the traffic. 2. Integrity: nobody can tamper with the traffic without detection. 3. Authentication: the server proves it is really example.com, using a certificate signed by a trusted Certificate Authority. The handshake: the client and server agree on a cipher, the server sends its certificate, they use asymmetric crypto (slow) just to agree a shared symmetric key, then all the actual data uses fast symmetric encryption with that key. Analogy: sealing a letter in a tamper-evident envelope (integrity), writing it in a code only you two share (encryption), and checking the recipient's ID card against a notary's stamp before you start (authentication). In an interview: HTTPS is HTTP over TLS. TLS gives encryption, integrity, and server authentication via a CA-signed certificate. The handshake uses slow asymmetric crypto only to agree a shared symmetric key, then encrypts the session with that.

Question 12

What is a socket?

Accepted Answer

Answer: A socket is one endpoint of a two-way network connection between two programs. It is identified by an IP address plus a port number. When a client and a server communicate over TCP, each side has a socket, and data written into one comes out of the other. A server 'listens' on a socket bound to a port (for example port 8080). When a client connects, the server gets a new socket dedicated to that client, so it can handle many clients at once. Your code reads and writes bytes to the socket like a stream. Higher-level things (HTTP libraries, database drivers) are built on top of sockets; you rarely use raw sockets directly. Analogy: a socket is like the two ends of a tin-can telephone. Each program holds one can, and the string between them carries the bytes both ways. In an interview: A socket is an endpoint of a network connection, identified by IP and port. The server listens on a port and gets a per-client socket on each accept, then reads and writes bytes like a stream. HTTP and DB drivers sit on top of sockets.

Question 13

What is SSH?

Accepted Answer

Answer: SSH (Secure Shell) is a protocol for logging into and running commands on a remote machine over an encrypted connection. It replaced older tools like Telnet, which sent everything, including passwords, in plain text. It usually runs on port 22. Authentication is by password or, better, by key pair: you keep a private key on your laptop and put the matching public key on the server, so you log in without a password and the private key never leaves your machine. SSH also powers scp and sftp (file copy), port forwarding (tunnelling), and is how Git talks to GitHub over git@github.com URLs. Analogy: a private, locked hallway to a remote computer's control room. You unlock it with a key only you hold, and everything you say inside is in a sealed tube. In an interview: SSH is an encrypted protocol for remote login and command execution, on port 22, replacing plaintext Telnet. Key-pair auth keeps the private key on your machine. It also underlies scp, sftp, tunnelling, and Git over SSH.

Question 14

What is the difference between a public key and a private key (asymmetric cryptography)?

Accepted Answer

Answer: Asymmetric cryptography uses a pair of mathematically linked keys. What one key locks, only the other can unlock. You keep the private key secret and share the public key freely. Two uses: Encryption: anyone encrypts a message with your public key, and only you, with the private key, can decrypt it. Signing: you sign data with your private key, and anyone can verify it with your public key. This proves the data came from you and was not changed. This is how TLS certificates and JWT signatures work. Asymmetric crypto is slow, so it is usually used just to exchange a fast symmetric key, which then does the bulk work. Analogy: a public mailbox slot: anyone can drop a letter in (encrypt with the public key), but only the person with the mailbox key (private key) can take letters out. In an interview: A linked key pair where one key undoes the other. Public key is shared, private key is secret. Encrypt with someone's public key so only they can read it; sign with your private key so anyone can verify it is you. It is slow, so it bootstraps a symmetric key.

Question 15

What is the difference between hashing, encryption, and encoding?

Accepted Answer

Answer: They look similar (data goes in, scrambled data comes out) but have different purposes. Encoding: converts data to another format for safe transport or storage (Base64, URL encoding, UTF-8). It is fully reversible by anyone, uses no key, and provides zero security. It is not a security tool. Encryption: scrambles data so only someone with the key can read it. It is reversible with the key (two-way). Used to protect data in transit (TLS) and at rest. Symmetric uses one shared key; asymmetric uses a public/private key pair. Hashing: runs data through a one-way function to a fixed-size digest. It is not reversible. The same input always gives the same hash, and a tiny change gives a completely different hash. Used for password storage, integrity checks, and data structures. Analogy: encoding is translating to Morse code (anyone can translate back). Encryption is a locked box (need the key). Hashing is a blender (you cannot un-blend a smoothie). In an interview: Encoding is a reversible format change with no security. Encryption is reversible with a key, for confidentiality. Hashing is one-way, for password storage and integrity. Base64 is encoding, not encryption, is the classic gotcha.

Question 16

How should you store user passwords?

Accepted Answer

Answer: Never store the password itself, and never encrypt it (encryption is reversible, so a key leak exposes everything). Store a slow, salted hash. 1. Salt: add a unique random value per user before hashing. This means two users with the same password get different hashes, and precomputed 'rainbow table' attacks do not work. 2. Use a deliberately slow password-hashing function: bcrypt, scrypt, or Argon2 (preferred today). They are tuned to take, say, 100ms per hash, so brute-forcing billions of guesses becomes infeasible. Do not use plain SHA-256, it is too fast. 3. On login, hash the entered password with the stored salt and compare. Use a constant-time comparison. Add a 'pepper' (a secret stored separately from the database) for extra protection. Analogy: you do not keep a copy of everyone's house key. You keep a smudged, salted fingerprint that is slow to fake and useless if stolen. In an interview: Store a per-user salted hash using a slow function like Argon2, bcrypt, or scrypt, never plaintext or reversible encryption, never fast unsalted hashes. Salt defeats rainbow tables; slowness defeats brute force.

Question 17

What are the common web vulnerabilities (XSS, CSRF, SQL injection)?

Accepted Answer

Answer: SQL injection: user input is run as part of a SQL query. Fix: parameterised queries so data and code stay separate. XSS (Cross-Site Scripting): an attacker gets their JavaScript to run in another user's browser, usually because the app renders user input as HTML without escaping. Fix: escape output by context, use a templating engine that auto-escapes, and set a Content-Security-Policy. CSRF (Cross-Site Request Forgery): a malicious page makes the victim's browser send a state-changing request to a site where the victim is logged in, riding on their cookies. Fix: anti-CSRF tokens, SameSite cookies, and checking the Origin header. The theme: never trust input, and be careful about the boundary where data becomes code (SQL, HTML, a shell command). Analogy: each one is 'attacker-controlled text ends up somewhere it is treated as instructions': in your database query, in someone's browser, or as an action on their behalf. In an interview: SQL injection is input executed as SQL (fix: parameterised queries). XSS is injected script running in a victim's browser (fix: output escaping, CSP). CSRF is a forged authenticated request (fix: CSRF tokens, SameSite cookies). All are untrusted input crossing into a code context.

Question 18

What are common API security risks, and how do you reduce them?

Accepted Answer

Answer, the ones that come up most (based on the OWASP API Top 10): Broken authentication: weak or missing token checks. Fix: verify tokens on every request, short expiry, refresh tokens. Broken object-level authorization: user A can fetch user B's record just by changing the id in the URL (GET /orders/123). Fix: check ownership on every request, not just that the caller is logged in. Excessive data exposure: the API returns full objects and the client hides fields. Fix: return only what is needed. No rate limiting: enables brute force and denial of service. Fix: throttle per client and per IP (429). Injection: same as SQL injection but also NoSQL and command injection. Fix: parameterise, validate. Also: always use HTTPS, validate all input, log and monitor, and keep dependencies patched. Analogy: most API breaches are not clever hacks. They are a missing ownership check, a token that is never really verified, or an endpoint with no rate limit. In an interview: The frequent ones are broken authentication, broken object-level authorization (changing an id in the URL), excessive data exposure, missing rate limiting, and injection. Fixes: verify tokens every request, check ownership per object, return minimal data, throttle, parameterise, and HTTPS everywhere.

Question 19

What is the difference between authentication and authorization?

Accepted Answer

Answer: Authentication (authn) is proving who you are. Logging in with a password, a one-time code, or a fingerprint. The result is an identity. Authorization (authz) is deciding what that identity is allowed to do. Can this user delete this document? Is this API key allowed to write? Authentication always comes first; authorization uses its result. In HTTP terms, 401 Unauthorized means authentication failed or is missing; 403 Forbidden means you are authenticated but not authorized for this action. Analogy: authentication is showing your ID at the door. Authorization is the guest list deciding which rooms your wristband opens. In an interview: Authentication proves identity; authorization decides permissions. Authn first, then authz uses the result. 401 is failed authentication, 403 is failed authorization.

Question 20

What is a session, and how does session auth compare to token auth?

Accepted Answer

Answer: Session auth: when you log in, the server creates a session record (in memory, a database, or Redis) and sends the browser a session ID in a cookie. On each request the browser sends the cookie, the server looks up the session, and knows who you are. Logout deletes the session, so revocation is instant. The cost is that the server must store and look up sessions, which is harder to scale across many servers. Token auth (JWT): the server sends a signed token that contains the user info. On each request the server just verifies the signature, no lookup, no server-side storage. It scales easily but you cannot revoke a token before it expires without extra machinery. Rule of thumb: sessions for classic server-rendered web apps, tokens for APIs and mobile clients. Analogy: a session is a coat-check ticket: the cloakroom keeps your coat and you hold a numbered stub. A token is a signed permission slip you carry that already says everything about you. In an interview: A session is server-side state keyed by an ID in a cookie: easy revocation, harder to scale. A token carries the user info signed, so the server verifies without a lookup: scales well, revocation needs extra work. Sessions for web apps, tokens for APIs.

Question 21

How do you implement role-based access control (RBAC)?

Accepted Answer

Answer: RBAC means you do not grant permissions to users directly. Instead: users are assigned roles (admin, editor, viewer), and roles are granted permissions (can_delete_post, can_publish). To check access, you look up the user's roles and see if any of them has the required permission. In practice the user's roles are put into their token or session at login. Each protected endpoint declares what it needs, and a middleware or annotation checks it before the handler runs. RBAC keeps things manageable: to change what all editors can do, you edit one role, not every editor. When roles are not enough (for example 'can edit only their own posts'), you add per-object ownership checks on top. Analogy: a building with keycard groups. You do not program each person's card room by room. You put them in the 'Engineering' group, and the group opens the engineering doors. In an interview: Assign permissions to roles and roles to users, not permissions to users directly. Put roles in the token at login, and check the required permission in middleware per endpoint. Add per-object ownership checks where roles are too coarse.

Question 22

What is a JWT, and how does token-based authentication work?

Accepted Answer

Answer: A JWT (JSON Web Token) is a signed, self-contained token. It has three Base64 parts separated by dots: a header, a payload of claims (user id, roles, expiry), and a signature. The server signs it with a secret or private key, so it can verify the token was not tampered with, without a database lookup. The flow: the user logs in, the server returns a JWT, the client stores it and sends it on every request in the Authorization: Bearer header. The server verifies the signature and expiry and trusts the claims. This keeps the server stateless. Watch out: a JWT cannot be revoked before it expires (you need a denylist or short lifetimes plus refresh tokens), and the payload is readable by anyone (it is signed, not encrypted), so never put secrets in it. Analogy: a festival wristband. The gate checks the hologram (signature) and the date, and lets you in without phoning the box office. But once issued, they cannot easily cancel one wristband. In an interview: A JWT is a signed token carrying user claims and an expiry, so the server verifies it by signature alone and stays stateless. Sent as a Bearer header. Downsides: no easy early revocation, and the payload is readable, so use short lifetimes and no secrets inside.

Question 23

What are OAuth 2.0 and OpenID Connect?

Accepted Answer

Answer: OAuth 2.0 is a framework for delegated authorization: it lets an app get limited access to your data on another service without you giving that app your password. When you click 'Sign in with Google' and grant an app access to your calendar, that is OAuth. The app receives an access token scoped to specific permissions. OpenID Connect (OIDC) is a thin layer on top of OAuth 2.0 that adds authentication: it also returns an ID token (a JWT) that tells the app who the user is. OAuth alone answers 'what can this app access'; OIDC adds 'and here is who logged in'. So 'Log in with Google' is really OIDC; 'let this app post to your Twitter' is plain OAuth. Analogy: OAuth is a valet key: it starts the car and opens the doors but not the boot. OIDC adds a note in the glovebox saying who handed over the key. In an interview: OAuth 2.0 delegates limited access to your data without sharing your password, issuing scoped access tokens. OpenID Connect adds an identity layer on top, returning an ID token so the app knows who you are. Social login is OIDC.

Question 24

What is token introspection?

Accepted Answer

Answer: Token introspection is an endpoint on the authorization server that another service calls to ask 'is this token still valid, and what is in it?'. The service sends the token, and the server replies with active: true/false plus the claims (user, scopes, expiry). It is used with opaque tokens (random strings that carry no readable data) and when you need real-time revocation: a self-contained JWT stays valid until it expires, but an introspection call checks the live state every time, so a revoked token is rejected immediately. The trade-off is a network call per request, so services often cache the result for a short time. Analogy: instead of trusting a wristband's hologram, the guard radios the box office each time to ask 'is band 4471 still good?'. Slower, but they can cancel a band instantly. In an interview: Introspection is asking the auth server whether a token is still active and what it contains. It is used with opaque tokens and when you need immediate revocation, trading a per-request call (often cached) for live validity checks.

Question 25

Where should you store an authentication token in the browser: a cookie or localStorage?

Accepted Answer

Answer: Prefer an httpOnly cookie. Use localStorage only when you have a specific reason and understand the risk. localStorage: any JavaScript on the page can read it. If an attacker gets ANY script to run (an XSS hole, a compromised npm package, a bad third-party script), they can steal the token and use it anywhere. It is also not sent automatically, so you attach it yourself in an Authorization header. httpOnly cookie: JavaScript cannot read it at all, so XSS cannot steal it. The browser sends it automatically with requests to your domain. The trade-off is that automatic sending enables CSRF, so you must also set SameSite=Lax or Strict (and use anti-CSRF tokens for cross-site form posts), set Secure so it is HTTPS-only, and scope it with Path and Domain. Common setup: a short-lived access token and a longer refresh token, both in httpOnly, Secure, SameSite cookies. Analogy: localStorage is a key left on the hallway table: anyone who gets into the house can take it. An httpOnly cookie is a key the front desk holds and swipes for you, but never hands over. In an interview: An httpOnly, Secure, SameSite cookie is the safer default because JavaScript cannot read it, so XSS cannot steal the token. localStorage is fully exposed to any script on the page. The cost of cookies is CSRF, which you handle with SameSite and anti-CSRF tokens.

Web, security & networking interview preparation

How the web works

HTTP and APIs

Networking basics

Security basics

Authentication and tokens