25 Cybersecurity Interview Questions & Expert Answers

Security interviews are unlike any other engineering loop because the subject is an adversary. Every other discipline asks "will it work?" Security asks "how will it be made to fail?" Interviewers want to see that adversarial reflex — the instinct to ask what an attacker controls, what they can observe, and what breaks first. Cultivate that instinct and the technical questions mostly answer themselves.

The core idea: Security is defence in depth against an intelligent opponent who only needs to succeed once. No single control is trusted; every layer assumes the one above it has already failed.

The question taxonomy

• Web application security. The OWASP classics: injection, XSS, CSRF, broken access control. Expect to explain and mitigate.
• Threat modelling. "Here's a system — how would you attack it?" Structured approaches like STRIDE help, but the thinking matters more than the acronym.
• Cryptography, applied. Hashing vs encryption vs encoding, TLS at a high level, why you never roll your own.
• Network and infrastructure. Segmentation, least privilege, zero trust principles.
• Detection and response. Logging, indicators of compromise, what you'd do with a suspected breach.

Worked example: SQL injection, end to end

"Explain SQL injection and how you prevent it." Cover all four beats — mechanism, impact, fix, and layered defence:

-- Vulnerable: string concatenation lets input become SQL
query = "SELECT * FROM users WHERE name = '" + user_input + "'"

-- Safe: parameterised query — input is data, never code
cursor.execute(
    "SELECT * FROM users WHERE name = %s",
    (user_input,)
)

Then the layers: parameterised queries as the primary fix, an ORM that defaults to safe behaviour, least-privilege database accounts so a successful injection can't drop tables, and a WAF as a speed bump — never as the fix itself. Explaining why each layer exists (because the one above it might fail) demonstrates defence in depth rather than reciting it.

How answers get scored

Rubrics reward attacker thinking ("what does the attacker control here?" should be your first sentence in any scenario), precise terminology (hashing is not encryption; authentication is not authorisation), and pragmatism — security that users route around is worse than none. In incident scenarios, containment before eradication, and evidence preservation before heroic cleanup, are the marks of someone who'd be trusted during a real breach.

Common mistakes

• Encoding or encrypting passwords instead of hashing them with a slow, salted algorithm like bcrypt or Argon2.
• Treating the perimeter as the defence — "it's on the internal network" has ended many careers.
• Fixing the specific vulnerability in a scenario without mentioning the class of vulnerability it belongs to.
• Answering "how would you attack this?" with defences. Answer the question that was asked.

The threat-modelling round

"Here's a system that stores customer documents — walk me through how you'd assess it." Resist the urge to list vulnerabilities. Instead, model like an engineer: what assets matter (the documents, the credentials guarding them), who the adversaries are (external attackers, malicious insiders, careless employees), what the trust boundaries are (every place data crosses from one control domain to another — the upload endpoint, the database, the support tool that can read anything), and what happens at each boundary if the attacker controls the input. Then prioritise by impact and likelihood, and only then propose controls, matched to the specific threats you named. The rubric rewards that order — assets, adversaries, boundaries, then controls — because it's how real assessments run. Candidates who jump straight to "encrypt everything and add a WAF" have described spending, not security.

FAQ

Do I need certifications to pass the interview? Certifications help get the interview; the interview itself tests reasoning. A candidate who thinks adversarially with no cert beats a certified candidate who recites definitions.

How much coding is expected? Enough to read code and spot the injection, the missing access check, the hardcoded secret. For application-security roles, expect to write exploit proofs-of-concept and fixes.

For the engineering fundamentals underneath, see the backend interview guide, and pressure-test your scenario answers with Aissence practice.