Security engineer at Cisco

As asked

Your product is adding a feature where users can upload arbitrary files to share with other users. Threat model it.

Sample answer outline

Use STRIDE or a similar framework. Spoofing: who can upload, is auth required, is the user-id on the upload trusted. Tampering: file type lying about MIME (sniff the content, do not trust the header), filename traversal, content-disposition tricks. Repudiation: audit log of uploads. Information disclosure: are files private by default, signed URLs with expiry. Denial of service: max file size, rate limits, virus scanning. Elevation of privilege: stored XSS via uploaded HTML, malware delivery, hosting attacker-controlled JS. Concrete mitigations: serve user content from a separate origin, force download for unknown types, scan async, signed URLs.

Expect these follow-ups

• How do you serve user-uploaded images without enabling stored XSS?
• What is your virus scanning policy and what do you do on a positive hit?
• How would you handle the same feature for a regulated industry (healthcare, finance)?

As asked

Walk me through the current OWASP Top 10. For each category, give a concrete example of a vulnerability you have seen or remediated.

Sample answer outline

The current Top 10 covers broken access control, cryptographic failures, injection, insecure design, security misconfiguration, vulnerable and outdated components, identification and authentication failures, software and data integrity failures, security logging and monitoring failures, and SSRF. The strong answer pairs each with a war story: a missing authorisation check on an admin endpoint, an unsalted password hash, a SQL injection through a dynamic ORDER BY, an SSRF that hit the cloud metadata service. The point is to show you have seen these in the wild, not to recite definitions.

Expect these follow-ups

• Which Top 10 category is most common in your experience?
• How does the Top 10 differ from the API Security Top 10?
• What is missing from the Top 10 that you would add?

As asked

An engineer commits an AWS access key to a public GitHub repo. Walk me through what you do in the next hour.

Sample answer outline

Treat the key as compromised. Rotate immediately, do not wait. Revoke the old key, generate a new one, push it via the secret manager so dependent services pick it up. Check CloudTrail for any usage of the key in the window between commit and rotation, especially from unfamiliar IPs. Remove the key from history (git filter-repo or BFG) but understand that GitHub may have already cached it and bots scrape new commits within seconds, so rotation is what matters, not rewriting history. Talk to the engineer without blame, and add pre-commit hooks (gitleaks, trufflehog) so it does not happen again.

Expect these follow-ups

• Why is rewriting history less important than rotating?
• How would you scan all current repos for past leaks?
• What is your policy for repeat offenders?

As asked

Walk me through exactly what happens during a TLS 1.3 handshake, from the initial ClientHello to when application data starts flowing. What changed compared to TLS 1.2 and why do those changes matter?

Sample answer outline

A strong answer covers the 1-RTT handshake in TLS 1.3, key exchange via ECDHE in the first flight, removal of RSA key exchange and static DH, the encrypted EncryptedExtensions and Certificate messages, and the introduction of 0-RTT resumption with its replay risks. The candidate should explain why forward secrecy is now mandatory and how the removal of legacy cipher suites reduces the attack surface.

Expect these follow-ups

• What are the security implications of 0-RTT resumption and when would you disable it?
• How does certificate pinning interact with TLS 1.3?

As asked

Given an OAuth 2.0 authorization code flow where the resource server validates JWTs locally using a cached public key, walk me through your threat model. What are the concrete attack surfaces and how would you mitigate each?

Sample answer outline

A strong answer covers authorization code interception and PKCE as the mitigation, JWT algorithm confusion attacks (e.g. alg:none, RS256-to-HS256 swap), key rotation lag allowing forged tokens during a compromise, token replay across audience boundaries, and the absence of server-side revocation with local validation. The candidate should mention short expiry windows, strict aud/iss validation, and JWKS refresh hygiene.

Expect these follow-ups

• How would you handle a situation where a signing key is compromised and you need to revoke all existing tokens immediately?

As asked

Compare DOM-based XSS to reflected XSS. How does the exploitation differ, why is DOM-based XSS harder to detect with traditional scanners, and what would you look for in a code review to find DOM sinks?

Sample answer outline

A strong answer explains that reflected XSS travels through the server and back in the HTTP response, making it detectable via HTTP response scanning, while DOM-based XSS never touches the server because the payload stays in the browser's DOM processing. The candidate should name dangerous sinks like innerHTML, eval, and location.href assignment, and contrast with dangerous sources like location.hash, document.referrer, and postMessage data. Manual code review and browser-based dynamic scanners are needed for DOM XSS.

Expect these follow-ups

• How would you implement a Content Security Policy to mitigate XSS and what are its common bypasses?