Security Engineer interview questions

The CIA triad states the three core security goals: confidentiality, integrity, and availability.

• Confidentiality limits payroll data to authorized readers.
• Integrity detects unauthorized changes, for example with a signed release artifact.
• Availability keeps a service usable through redundancy, backups, and denial-of-service protection.

A threat can cause harm, a vulnerability is a weakness, and risk combines the likelihood and impact of exploitation.

• An internet attacker is a threat; an unpatched public server is a vulnerability.
• Risk rises when that server stores customer data and a working exploit is public.
• Patching or restricting exposure lowers risk even though the threat remains.

Likelihood estimates how probable an event is, while impact estimates its damage.

• Active exploitation makes a public service more likely to be attacked than an isolated lab host.
• Loss of a test page has less impact than theft of production payment data.
• Teams use both dimensions to prioritize work instead of treating every finding equally.

An attack surface is every reachable point where an attacker can interact with a system.

• It includes APIs, ports, login pages, uploads, accounts, integrations, and physical access.
• Forgotten subdomains and unused admin endpoints still count while reachable.
• Removing an unnecessary service or permission is stronger than only monitoring it.

Least privilege gives each user and service only the permissions needed for its current job.

• A reporting service that reads invoices should not have database delete rights.
• Administrative access should be temporary rather than attached to a daily account.
• Periodic reviews remove access that remains after a role or responsibility changes.

Defense in depth uses independent layers so one failed control does not expose the whole system.

• Parameterized queries prevent SQL injection; limited database rights reduce remaining damage.
• MFA helps after password theft; session monitoring can still detect abuse.
• Tested backups reduce impact when preventive and detective controls both fail.

A team can avoid, reduce, transfer, or accept a risk after assessing it.

• Avoidance can retire an unused public service; reduction can patch it and restrict access.
• Insurance or contracts transfer some loss but do not remove technical responsibility.
• Acceptance must be explicit, time-bounded, documented, and owned by an authorized person.

The control type says whether it stops an event, reveals it, or restores a safe state.

• MFA is preventive because it blocks many logins using stolen passwords.
• An impossible-travel alert is detective because it reveals suspicious account use.
• Revoking sessions and restoring a backup are corrective actions after compromise.

Secure by default means a new system starts in the safer state without manual hardening.

• New accounts receive no privileged role until it is deliberately granted.
• A new storage bucket starts private rather than publicly readable.
• Compatibility options must not silently disable TLS checks, authentication, or audit logs.

A trust boundary is where data or control crosses between components with different trust levels.

• Browser input crossing into an API is untrusted even when the normal UI created it.
• An application calling a database crosses a boundary controlled by credentials and network rules.
• Each crossing needs caller identification, validation, authorization, and useful security logging.

Every client-controlled part of an HTTP request is untrusted.

• Paths, query values, headers, cookies, and bodies can all be changed with curl or a proxy.
• Content-Type describes data but does not prove that the data is safe.
• The server validates type, length, format, business rules, and authorization before use.

HTTP methods express intent, so controls should match whether a request reads or changes state.

• GET and HEAD should not delete data because links and crawlers may trigger them.
• State-changing methods need authorization and CSRF protection with cookie sessions.
• A method name is not access control, so every endpoint still checks permission.

Errors should help the client act without exposing internals useful to an attacker.

• Return a stable message, not a stack trace, SQL query, filesystem path, or secret.
• Log details server-side with a correlation ID that support can match to the response.
• Login errors should avoid confirming whether a particular account exists.

Session cookies normally use Secure, HttpOnly, and an appropriate SameSite value.

• Secure sends the cookie only over HTTPS.
• HttpOnly blocks JavaScript reads, limiting token theft during many XSS attacks.
• SameSite reduces cross-site sending; narrow Domain, Path, and expiry further limit exposure.

The same-origin policy stops a page from freely reading data from another origin.

• An origin combines scheme, host, and port, so HTTP and HTTPS origins differ.
• Some cross-origin requests can be sent, but JavaScript usually cannot read their responses.
• CORS relaxes this boundary for approved origins; forms and embedded resources follow separate rules.

CORS is a browser-enforced policy controlling which origins may read cross-origin responses.

• The browser sends Origin and may issue a preflight OPTIONS request.
• Servers should allow specific origins, especially when credentials are enabled.
• CORS is not authentication, does not stop curl, and does not replace CSRF protection.

Client validation improves usability, but the user controls the client.

• An attacker can remove JavaScript checks, edit hidden fields, or use Burp Suite.
• The server must enforce value, size, business-rule, and ownership checks.
• Hiding an admin button does not protect the underlying endpoint from direct requests.

TLS provides confidentiality, integrity, and endpoint authentication for data in transit.

• Encryption prevents a network observer from reading application traffic.
• Integrity checks make undetected modification impractical.
• Certificate validation confirms server identity, but TLS does not make application code safe.

A certificate warning means the browser could not establish a trusted identity for the site, so do not bypass it or enter sensitive data.

• Check the URL and your device clock because a wrong hostname or invalid date can trigger a warning.
• The browser normally checks the hostname and a certificate chain leading to a trusted certificate authority.
• Stop and report the warning; do not enter passwords or payment data until the problem is fixed.

DNS finds an IP for a hostname, a port selects a service, and a firewall controls connections.

• A browser can resolve app.example.com and connect to TCP port 443.
• The hostname still matters for TLS validation and HTTP virtual hosting.
• An allowed port still needs secure code, authentication, and authorization behind it.