Web Security Fundamentals

Cover this or you fail the question

• TLS on every connection, including internal ones. The old model of a hard perimeter with an unencrypted soft interior fails as soon as anything inside is compromised, which is the ordinary case rather than the exotic one.
• TLS provides three things worth naming separately, because candidates usually name only the first: confidentiality so traffic cannot be read, integrity so it cannot be altered undetected, and authentication of the server through its certificate so the client knows what it is talking to.
• A man-in-the-middle attack is what you are preventing: an attacker positioned between client and server who can read or modify traffic. Certificate validation is the specific control that stops it, which is why an application that disables certificate checking to make an error go away has removed the protection entirely while appearing to still use TLS.
• HTTP Strict Transport Security tells the browser to refuse plain HTTP for the domain in future, which closes the window where a first request over HTTP could be intercepted and redirected.

Common trap: Saying 'we use HTTPS' and stopping. The follow-up is always what HTTPS actually gives you, and an answer that cannot separate encryption from server authentication does not survive it.

Cover this or you fail the question

• Authentication answers who a party is; authorisation answers what they may do. Keeping them distinct matters practically — a large share of real vulnerabilities are cases where a correctly authenticated user reached something they were not entitled to.
• Passwords are stored as salted hashes using an algorithm deliberately designed to be slow, so that a stolen database is expensive to attack offline. A fast general-purpose hash is the wrong tool and is a specific, checkable mistake.
• A second factor matters more than password complexity rules, because it defeats the attack that actually happens: credentials reused from another site's breach, or handed over in a phishing flow.
• After login, a session identifier or token carries the identity. It must be unguessable, transmitted only over TLS, marked so client-side script cannot read it, and given an expiry — and it must be possible to invalidate it before that expiry.

Cover this or you fail the question

• Every value from a client is attacker-controlled, including headers, cookies and hidden form fields that the interface never intended to be editable.
• Injection is prevented structurally rather than by filtering: parameterised queries keep data out of the SQL grammar, so no amount of quoting in the input changes what the query does. Escaping by hand is the approach that keeps failing.
• Cross-site scripting is the same class of problem in the browser — data ending up interpreted as code — and is prevented by encoding output for the context it lands in, with a content security policy as the backstop for what gets through.
• Authorisation is checked on the server for every request. A client that hides a button has changed the interface, not the permission, and the request can still be sent directly.

Common trap: Proposing a blocklist of dangerous strings. Blocklists are enumerable and attackers enumerate them; the structural fixes above do not depend on anticipating the payload.

What separates a solid answer

• Credentials live in a managed secret store, retrieved at runtime by a workload that proves its identity to the platform, rather than in code, configuration files or environment variables baked into an image.
• Long-lived static credentials are the highest-value thing an attacker can find, which is why short-lived, automatically rotated credentials tied to a workload identity are the direction to argue for.
• A secret committed to version control is compromised even after the commit is removed, because history persists and repositories get cloned. The response is rotation, not deletion.
• Encryption at rest protects a specific threat — someone obtaining the storage medium or a backup — and does not protect against an application that is tricked into reading the data itself. Being clear about which threat a control addresses is what distinguishes understanding from recitation.

What separates a solid answer

• OAuth 2.0 is an authorisation framework for delegated access: it lets one application act on a user's behalf against another without ever seeing that user's password. The user is redirected to the provider, approves a defined scope, and the application receives a token limited to that scope.
• OpenID Connect is the thin identity layer on top of OAuth. The distinction is worth stating because it is the most common confusion in this area: OAuth on its own tells you an application was granted access, not who the user is, and using an access token as proof of identity is a real and recurring mistake.
• SAML solves a similar problem in a different era and style — XML assertions, typically browser-redirect based, and dominant in enterprise single sign-on. Encountering it usually means integrating with a corporate identity provider rather than a consumer one.
• What both buy operationally is one place where identity lives: access is granted by group membership and removed everywhere at once when someone leaves, instead of accounts accumulating in every individual system.

What separates a solid answer

• A web application firewall inspects requests for known attack patterns before they reach the application. It is genuinely useful, particularly as a fast way to block a newly disclosed exploit while the real fix ships, and it is not a substitute for the application being correct.
• Rate limiting and bot management protect against credential stuffing and scraping, which are volume attacks that individually look like ordinary valid requests.
• Distributed denial of service is absorbed at the network edge by a provider with the capacity to do so; it is not solvable in application code, and saying so is the correct answer rather than an evasion.

The senior signal

• The senior framing is that prevention is incomplete by definition, so the design is judged on what a compromise reaches. Segment so that one compromised component cannot access everything; grant the narrowest permissions that work; and prefer short-lived credentials so stolen ones expire.
• Logs go somewhere the compromised system cannot alter, because an attacker's first move after gaining access is frequently to remove the evidence of it.
• Revocation has to be fast and has to be practised. A token blocklist checked on the request path revokes access in seconds; waiting for tokens to expire naturally is not a revocation strategy.
• Dependencies are part of the attack surface and are the vector that has produced the largest recent incidents. Knowing what you ship, and being able to answer whether a newly disclosed vulnerability affects you, is an operational capability rather than a scanning tool.
• End-to-end encryption means only the communicating parties can read the content — the server relaying it cannot. It is the right answer for messaging and specific high-sensitivity flows, and its real cost is that features which depend on reading content, including server-side search and moderation, stop being possible. Naming that trade is what separates understanding it from having heard of it.