Top Ethical Hacker Interview Questions & Answers (2026)

SQL injection happens when an application builds a database query by mixing user input in as code rather than data, so the input can change the query's logic. Impact ranges from reading other users' data to modifying records, depending on the database account's permissions. The real fix is parameterized queries or prepared statements everywhere, so input is always treated as data, plus least-privilege database accounts to limit damage. Input validation and a web application firewall are useful extra layers, not the fix. For detection, application and database logs showing query errors or odd patterns, plus WAF alerts, help, and code review and static analysis in the pipeline catch it before release.

I start by understanding the app as a user: its functions, roles, data and trust boundaries, and I map every input and endpoint, including APIs. I use the OWASP Web Security Testing Guide as a checklist and the OWASP Top 10 as a sanity check. Key areas are authentication and session management, access control, especially whether one user can reach another's data or admin functions, injection, input handling and output encoding for cross-site scripting, business logic flaws, security misconfiguration and vulnerable components. Access control and logic issues need manual testing because scanners miss them. For every finding I record evidence and a fix developers can act on.

Privilege escalation is moving from limited access to higher rights, either vertically, from a standard user to an administrator, or horizontally, into another account with different access. In Windows domains it usually comes from misconfiguration rather than exotic flaws: users with local admin rights, the same local administrator password on many machines, credentials left in scripts, unpatched systems or over-permissioned service accounts. Defences include least privilege, removing standing admin rights, unique local admin passwords managed by Microsoft LAPS, tiered administration so domain admin credentials never touch workstations, prompt patching, and alerting on privileged group changes and unusual logons. In the report I focus on which control was missing.

I use a standard such as CVSS, now at version 4.0, so ratings are consistent and defensible, but I don't stop at the base score. I adjust for context: how exposed the asset is, what data it holds, whether the weakness is being exploited in the wild, and what compensating controls exist. A medium-scored flaw on an internet-facing payment system can matter more than a high on an isolated lab server. I also look at chains, where several moderate issues together form a critical path to sensitive data. Each finding gets a clear severity rationale, evidence, impact in business terms and a practical, prioritized fix.

Social engineering manipulates people rather than systems, through phishing, phone pretexting or physical tailgating, exploiting trust, urgency or authority. For a phishing assessment I'd agree in writing which staff are in scope, which pretexts are off limits, such as fake layoffs, bonuses or health scares that cause real distress, what data we collect and how it's protected, and who on the client side knows about the test. The goal is measuring organizational resilience and reporting rates, not shaming individuals, so results are aggregated. Recommendations focus on controls like email filtering, MFA, an easy report button and training, plus recognizing staff who reported the test.