Cybersecurity Engineer Top 100 Interview Questions

Authentication proves who someone is; authorization decides what that proven identity is allowed to do. Authentication happens first, but passing it says nothing about which data or actions a user should reach.

Points that matter in practice:

• Most serious web application flaws are authorization failures: the user is genuinely logged in but reaches data that is not theirs by changing an ID.
• Authorization must be enforced on the server for every request. Hiding a button in the user interface is not access control.
• Keep authorization rules in one shared place, such as a policy module, so they are applied consistently.

Interview tip: the confusing status code names are a common trick question; 401 actually means "not authenticated", while 403 means "authenticated but not allowed".

Multi-factor authentication is phishing-resistant when the user cannot hand a usable secret to a fake website. The strongest methods sign a challenge with a private key that never leaves the device, and the signature is bound to the real website's address.

Why the strongest methods resist phishing:

• The browser tells the authenticator which website is asking. A look-alike domain gets a signature that is useless on the real site.
• There is no code for the user to read out or type, so nothing can be relayed.
• The private key cannot be exported, so it cannot be stolen from a server breach either.

The weak point then becomes account recovery. Protect recovery and help-desk resets as strongly as the login itself.

SAML is an XML-based standard for single sign-on, mostly used for enterprise web applications. OAuth 2.0 is a framework for delegated authorization, letting an app call an API on a user's behalf. OpenID Connect adds a standard login layer on top of OAuth 2.0.

When to use which:

• Use SAML when integrating with enterprise applications that only support it.
• Use OAuth 2.0 when an application needs scoped access to an API.
• Use OpenID Connect for new login integrations, especially for mobile and single-page apps.

A common mistake is treating an OAuth access token as proof of who logged in. Access tokens are meant for the API, so use the OpenID Connect ID token to establish identity.

The application sends the user to the authorization server to log in, receives a short-lived authorization code, and exchanges that code for tokens. PKCE adds a one-time secret so that only the app that started the flow can redeem the code.

1. The app creates a random code_verifier and derives code_challenge = BASE64URL(SHA256(code_verifier)).
2. It redirects the user to the authorization server with its client ID, redirect address, scopes, a random state value and the code challenge.
3. The user logs in and consents; the server redirects back with a code and the same state.
4. The app checks that state matches, which blocks forged callbacks.
5. The app sends the code plus the original code_verifier to the token endpoint.
6. The server hashes the verifier, compares it with the stored challenge, and only then returns tokens.

sequenceDiagram
  participant U as User browser
  participant A as App
  participant S as Authorization server
  A->>U: Redirect with code challenge and state
  U->>S: Log in and consent
  S->>U: Redirect back with code and state
  U->>A: Code and state
  A->>S: Code plus code verifier
  S->>S: Hash verifier and compare with challenge
  S->>A: Access token and refresh token

PKCE matters because codes can leak through browser history, logs or a malicious app registered for the same redirect address. A leaked code is useless without the verifier, which never left the app.

A JSON Web Token is a compact, signed set of claims written as header.payload.signature, with each part Base64URL-encoded. The signature proves the claims were issued by the key holder and not changed, but the payload is readable by anyone.

Mistakes that make validation unsafe:

• Trusting the token's alg header: accepting none, or letting an attacker switch from an asymmetric algorithm to an HMAC one keyed with the public key. Pin the expected algorithm on the server.
• Skipping claim checks: always validate the expiry, the issuer and the audience, so a token for another service is rejected.
• Weak HMAC secrets: a short secret can be brute-forced offline from any captured token.
• Following key URLs from the header: fetching keys from a location the token names lets attackers supply their own key.
• Putting secrets in the payload: it is encoded, not encrypted.
• Long lifetimes with no revocation: keep access tokens short-lived and use refresh tokens that the server can revoke.

Use a maintained library with an explicit configuration for algorithm, issuer, audience and clock skew, rather than decoding tokens by hand.

Session cookies carry the user's authenticated session, so their attributes decide who can read them, where they are sent and how long they live. Set them deliberately rather than relying on defaults.

Session handling beyond attributes:

• Issue a new session ID at login to prevent session fixation, where an attacker plants a known ID before the victim logs in.
• Invalidate the session on the server at logout; deleting the cookie alone leaves a stolen copy valid.
• Apply both an idle timeout and an absolute lifetime, shorter for sensitive applications.
• Bind sensitive actions, such as changing a password, to a fresh re-authentication.

Role-based access control grants permissions to roles and assigns users to roles. Attribute-based access control decides each request from attributes of the user, the resource, the action and the context, evaluated against policies.

When to use which:

• Use roles for most applications and for administrative permissions; they are easy to explain and review.
• Add attributes where access depends on data, such as ownership, region, data classification or tenant.
• Many systems combine both: roles decide which actions exist for a user, and attribute or ownership checks decide which records those actions apply to.

Whichever model you use, centralize the decision in one policy component and log every denial.

Privileged access management controls, monitors and limits the accounts that can change systems, so that a stolen or misused admin credential does far less damage. The aim is to remove standing admin power wherever possible.

Core practices:

1. Inventory every privileged account, including service accounts, shared root accounts and cloud administrators.
2. Separate accounts: administrators use a dedicated admin identity, never their everyday email and browsing account.
3. Store credentials centrally: shared and service passwords live in a secrets manager, are checked out when needed, and rotate automatically after use.
4. Grant just-in-time access: elevation is requested, approved for a stated task and expires after a set period.
5. Require strong authentication with phishing-resistant multi-factor authentication for every elevation.
6. Record and monitor sessions, so unusual commands raise alerts and investigations have evidence.
7. Keep break-glass accounts for emergencies, with alerts whenever they are used.

The measure of success is how few people hold admin rights at any given moment. Attackers who steal a normal account then have nothing powerful to escalate into.

Layer controls that make each guess expensive, spot automated patterns across many accounts, and make a correct password insufficient on its own. Different attacks need different signals.

Further controls:

• Rate limits by account, by source address and by network range, since stuffing attacks rotate addresses.
• Uniform responses: the same message and timing for unknown users and wrong passwords, so accounts cannot be enumerated.
• Careful lockouts: hard lockouts let attackers lock real users out, so prefer temporary delays or extra challenges.
• Monitoring: watch the global login success rate; a sudden drop with a spike in attempts signals an attack in progress.
• Notify users about new-device sign-ins so they can report account takeover quickly.

A time-based one-time password is an HMAC of the current 30-second time step, keyed with a secret shared between the server and the user's authenticator app, shortened to six digits.

1. Decode the shared secret, which apps exchange in Base32 inside a QR code.
2. Compute the counter: counter = floor(unix_time / 30), packed as an 8-byte big-endian integer.
3. Compute HMAC-SHA1(secret, counter).
4. Dynamic truncation: take the low 4 bits of the last byte as an offset, read 4 bytes from that offset and clear the top bit.
5. Take that number modulo 10^digits and pad with leading zeros.

Points for a production implementation:

• Allow small clock drift by also accepting the previous and next time step, but no more.
• Reject reuse: remember the last accepted step per user so an intercepted code cannot be replayed within its window.
• Rate-limit attempts, because six digits give only a million combinations.
• Compare in constant time and store the shared secrets encrypted.

These codes stop password-only attacks, but they can still be phished in real time. Use them where phishing-resistant keys are not yet possible.

SQL injection happens when an application builds a query by pasting user input into SQL text, so specially crafted input changes the query's meaning. A parameterized query sends the SQL and the values separately, so input is always treated as data and can never become code.

How the attack works:

1. The code builds ... WHERE name = ' + input + '.
2. The attacker enters x' OR '1'='1, closing the quote and adding a condition that is always true.
3. The database runs the altered query and returns every row. Other payloads can read other tables, change data or, on some databases, run commands.

How to prevent it:

• Parameterized queries or prepared statements for every value, in every query.
• Allowlists for identifiers, because table and column names cannot be parameters. Map user choices such as a sort field to fixed names in code.
• Least-privilege database accounts, so a successful injection reaches as little as possible.
• Avoid building SQL by hand in stored procedures and query builders too; string concatenation inside them is just as vulnerable.

Escaping input by hand is fragile and differs between databases, so treat it as a last resort.

Cross-site scripting lets an attacker run their script in another user's browser on your site, where it can steal data, act as the user or change the page. The three types differ in where the malicious script comes from.

Prevention that covers all three:

• Context-aware output encoding: HTML body, attributes, JavaScript strings and URLs each need different encoding. Templating engines with automatic escaping handle most cases.
• Avoid dangerous sinks such as assigning to innerHTML or building code from strings; use textContent and DOM methods instead.
• Sanitize rich text with a well-maintained HTML sanitizer when users must be able to format content.
• Content Security Policy as a second layer, blocking inline scripts and limiting where scripts load from.
• HttpOnly cookies to limit what a successful attack can steal.

Input validation helps but cannot replace output encoding. The same value can be safe in one context and dangerous in another.

Cross-site request forgery tricks a logged-in user's browser into sending a request the user did not intend. It works because browsers automatically attach the site's cookies to requests, even when another website triggers them.

sequenceDiagram
  participant U as Victim browser
  participant E as Attacker page
  participant B as Bank site
  U->>B: Log in, receive session cookie
  U->>E: Visit attacker page
  E->>U: Hidden form that posts a transfer to the bank
  U->>B: Transfer request with session cookie attached
  B->>B: Cookie is valid, transfer accepted

Further points:

• Never change state with GET requests, because links and images can trigger them.
• APIs that read a token from a custom header, not from a cookie, are not exposed to this attack, since attacker pages cannot set that header across sites.
• Cross-site scripting defeats every forgery defense, because injected script runs on your own origin.

Server-side request forgery happens when an attacker makes your server send requests to a destination of the attacker's choosing, usually by supplying a URL to a feature such as "import from link" or "fetch a preview". The server's network position and credentials then work for the attacker.

Why it is dangerous in the cloud:

• Instance metadata: cloud servers can reach a local metadata address, such as 169.254.169.254, that can return temporary credentials for the server's role.
• Internal services: admin panels, databases and other services trust requests from inside the network.
• Port scanning from inside: response times and errors reveal the internal network layout.

flowchart LR
  A["Attacker"] -->|URL to fetch| B["Vulnerable app server"]
  B -->|request| C["Metadata address"]
  C -->|temporary credentials| B
  B -->|response shown| A
  A -->|uses credentials| D["Cloud storage and APIs"]

Defenses:

1. Allowlist the destinations and schemes the feature may fetch, rather than blocking known-bad addresses.
2. Resolve and check the address before connecting, reject private, loopback and link-local ranges, and connect to the address you checked, so a DNS change cannot swap it.
3. Disable redirects, or validate every hop again.
4. Require session tokens on the metadata service and give servers minimal roles.
5. Restrict egress from servers that fetch user-supplied URLs.

Broken object-level authorization means an API returns or changes a record without checking that the caller is allowed to access that specific record. The user is properly logged in, but changing an ID in the request reaches someone else's data.

Why it is common:

• Frameworks handle authentication globally, but object ownership checks must be written per endpoint, and some get missed.
• Hard-to-guess IDs such as random identifiers make it less obvious but do not fix it, because IDs leak through links, logs and other responses.

How to test for it:

1. Create two test accounts in the same role, and if possible a third in another tenant.
2. With account A, create resources and record their IDs.
3. With account B's token, request each of A's resources through every method: read, update, delete and any custom actions.
4. Try IDs in every location: the path, query string, request body and nested objects.
5. Check list and search endpoints, and exports, for records that leak across accounts.
6. Expect a 403 or 404 response every time. A 200, or a change that took effect, is a finding.

How to fix it: enforce ownership in a shared data-access layer, for example by always filtering queries on the caller's tenant and user, rather than in each controller.

Path traversal happens when user input becomes part of a file path and sequences such as ../ walk out of the intended folder. The reliable defense is to resolve the final path and confirm it is still inside the allowed base directory before opening it.

Key points:

• Avoid user-supplied paths entirely when possible: store files under generated IDs and look up the real path in a database.
• Resolve, then check: compute the absolute, normalized path, following any symbolic links, and verify it starts inside the base folder. Checking the raw string for ../ misses encoded and nested variants.
• Reject absolute paths and drive letters, which can replace the base path when joined.
• Decode before checking, and decode only once, so %2e%2e%2f cannot slip past.
• Run with least privilege so that even a successful traversal cannot read secrets such as configuration files or keys.

Archive extraction has the same flaw: entries named ../../file can be written outside the target folder, so apply the same resolve-and-check rule to every entry.

Treat every uploaded file as hostile: check what it really is, limit it, store it where it cannot execute, and serve it so the browser cannot treat it as part of your site.

1. Allowlist file types by checking the file's content signature, not just its extension or the content type the client claims.
2. Limit size and count per file and per user, and reject compressed files that expand enormously.
3. Rename files to random identifiers and keep the original name only as metadata.
4. Store outside the web root, ideally in separate object storage, so an uploaded script can never be executed by the web server.
5. Serve from a separate domain with Content-Disposition: attachment and X-Content-Type-Options: nosniff, so a disguised HTML file cannot run scripts on your main domain.
6. Scan for malware before making files available to other users.
7. Re-encode images and strip metadata, which removes hidden payloads and location data.
8. Keep parsers patched, because image, document and archive libraries are a frequent source of serious vulnerabilities.

Process uploads asynchronously in an isolated worker with minimal permissions. A parser exploit then lands in a sandbox rather than on the main application server.

Many languages have native serialization formats that can recreate arbitrary objects and call their methods while doing so. If an attacker controls the serialized data, they can choose which objects are built, and chains of existing classes, called gadget chains, can end in running commands on the server.

What can go wrong:

• Remote code execution: the most severe outcome, from object construction or "magic" methods that run automatically.
• Authentication bypass: tampered session objects that claim a different user or role.
• Denial of service: deeply nested or self-referencing structures that exhaust memory or CPU.

How to prevent it:

1. Use data-only formats such as JSON for anything crossing a trust boundary, and validate it against a schema.
2. Never deserialize native objects from cookies, request bodies, message queues or files that users can influence.
3. If you cannot avoid it, sign the data with an HMAC and verify the signature before deserializing, and restrict the classes allowed.
4. Run deserialization with least privilege and keep libraries patched, since new gadget chains are found regularly.

Interview tip: point out that the danger lies in the format's ability to create objects, not in the parsing itself; that is why switching to a data-only format fixes the class of bug.

An allowlist defines exactly what valid input looks like and rejects everything else; a denylist tries to list what is bad and accepts the rest. Attackers only need one variant the denylist forgot, while an allowlist fails safe.

When to use which:

• Use allowlists wherever the valid set is known: IDs, dates, enums, sort fields, file types, country codes and redirect targets.
• Use denylists only as an extra layer, such as blocking known-malicious addresses.
• For free text, such as names and comments, strict allowlists break legitimate input. Validate length and character encoding, then rely on output encoding and parameterized queries for safety.

Validate on the server, after decoding and normalizing the input. Client-side validation is for user experience only.

Security headers tell the browser to apply protections that the page itself cannot enforce. They are cheap to add and close whole classes of attacks, though they never replace fixing the application.

Rolling them out:

• Start a Content Security Policy in report-only mode, collect violation reports, fix them, then enforce.
• Add HSTS with a short max-age first, because a mistake locks users into HTTPS for the whole period.
• Do not rely on deprecated headers such as the old browser cross-site scripting filter; modern browsers ignore it.