Top 10 Web Application Security Interview Questions | Most Asked

In this blog, I’ve put together the Top 10 Application Security Interview Questions I’ve been asked in 20+ interviews for application security positions. Interviewers usually want to know if you understand key security concepts and how you’d handle real-life security challenges. They’ll ask about common vulnerabilities, how to test for them, and how to protect against them.

1. What is CSRF (Cross-Site Request Forgery)?

Answer:
CSRF is a type of attack where an attacker tricks a user into making unwanted requests on a website where they are logged in. The attacker uses the trust that the website has in the user’s browser.

Example:
Imagine you’re logged into your online banking account. If you click on a harmful link, it could secretly send money from your account without you knowing. This happens because your browser automatically sends your session cookies with the request, making it look like you’re the one making the request.

How CSRF Works:
– It relies on the fact that browsers send session cookies automatically.
– It works because the website doesn’t check if the request is coming from a trusted source.

2. How to Protect Against CSRF?

Answer:
Here are a few ways to protect against CSRF:

• CSRF Tokens: The server creates a unique token for each session. This token is added to forms. When the form is submitted, the server checks if the token is correct. If it’s missing or wrong, the request is rejected.
  Example:
  <input type="hidden" name="csrf_token" value="s3cr3tT0k3n">
• SameSite Cookies: Set cookies with SameSite to prevent sending cookies from other sites. For example, SameSite=Strict will block cookies from being sent in cross-site requests.
  Example Cookie:
  Set-Cookie: sessionid=abc123; SameSite=Strict; Secure; HttpOnly
• Double Submit Cookie: Store the CSRF token both in a cookie and in the form. The server checks both to see if they match.

Read our blog for CSRF protection: What is CSRF attack? Simplified for Beginners – CyberSecurityWaala

3. What is your approach for Web Application Penetration Testing?

Answer:
Here’s the process I follow when testing a web application for vulnerabilities:

• Reconnaissance (Finding Information):
  First, I look for all possible entry points, like subdomains or old pages. Tools like Sublist3r or Google Dorking can help find these hidden parts of the site.
• Mapping (Understanding the Structure):
  I use tools like Burp Suite to crawl the website and list all the pages and APIs that can be accessed. This helps me find potential weaknesses.
• Automated Scanning:
  Tools like OWASP ZAP and Nessus can scan for common problems like outdated software or known vulnerabilities.
• Manual Testing:
  I then test the website manually for specific attacks, such as:
  – SQL Injection: I try to manipulate input fields like login forms with something like ' OR 1=1--.
  – XSS (Cross-Site Scripting): I inject scripts into fields to see if they execute, such as <script>alert(1)</script>.
  – IDOR (Insecure Direct Object Reference): I try changing URL parameters to access data that doesn’t belong to me.
• Exploitation:
  Once I find a weakness, I try to exploit it to prove that it’s a real problem. For example, using sqlmap to exploit a SQL injection and dump a database.
• Reporting:
  Finally, I write a report with details of the vulnerabilities, their impact, proof, and how to fix them.

4. What are the test cases that can be performed on a Login Page?

Answer:
Here are the key tests I perform on a login page:

• SQL Injection:
  I test the login form by entering ' OR 1=1-- in the username and password fields. If the login works or I get an error, it’s vulnerable to SQL injection.
• Brute Force Protection:
  I check if the website limits the number of login attempts. If I can try many passwords without being blocked, it’s vulnerable to brute-force attacks.
• CSRF Tokens:
  I test if the login form has a CSRF token. If I can submit the form without a token and it still works, it’s vulnerable to CSRF.
• Error Messages:
  If I enter the wrong username and see a message like “Username not found,” attackers might use this to guess valid usernames. Error messages should be generic, like “Invalid credentials.”
• Password Policies:
  I check if weak passwords like “123456” or “password” are allowed. There should be rules in place to prevent weak passwords.
• HTTPS Enforcement:
  I ensure the login page uses HTTPS, not HTTP, to prevent interception of data. I also check for mixed content, like HTTP images on an HTTPS page.

Pro Tip:
Use tools like Burp Suite to automate brute-force attacks and test how well the login page handles failed attempts.

5. What is SSRF & How Can We Mitigate It?

Answer:
SSRF (Server-Side Request Forgery) is an attack where an attacker tricks a server into making requests to internal services, often leaking sensitive information.

Example Attack:
Imagine an app that lets users input a URL to fetch images. The attacker could input a URL like http://169.254.169.254/latest/meta-data/ (an AWS metadata endpoint), and the server will fetch the cloud metadata, revealing sensitive data like credentials.

Mitigation:
– Allowlist URLs: Only allow requests to trusted URLs and block internal IP addresses like 127.0.0.1 or 192.168.x.x.
– Block Dangerous URL Schemes: Block unsafe URL schemes like file:// or ftp://.
– Network Segmentation: Ensure that your web servers can’t reach internal services or admin interfaces.

Pro Tip: Test SSRF vulnerabilities by entering a URL like http://burpcollaborator.net. If the server makes a request to that URL, SSRF is present.

6. What recommendation will you provide to a developer for SQL injection vulnerability that you have identified on a login page?

Answer:
Here’s what I would recommend:

• Use Parameterized Queries: Always use parameterized queries to separate user input from the query itself. This prevents attackers from injecting malicious SQL.
  Example:
  cursor.execute("SELECT * FROM users WHERE username = %s AND password = %s", (username, password))
• Use an ORM (Object-Relational Mapping): Frameworks like Django or Hibernate automatically use parameterized queries, which reduces the risk of SQL injection.
• Validate User Input: Only allow alphanumeric characters in usernames and reject inputs with special characters like ', ", or ;.
• Don’t Escape User Input: Avoid escaping characters manually (like \') because attackers can bypass it. Use parameterized queries instead.

7. As OAuth protocol is mainly used for authorization, how can we use it for authentication?

Answer:
OAuth is typically used for authorization, but it can be used for authentication when combined with OpenID Connect (OIDC). OpenID Connect is built on top of OAuth and adds a way to verify a user’s identity.

How It Works:
– OAuth lets users give permission to apps to access certain resources (e.g., letting Spotify post on Twitter).
– OpenID Connect adds authentication by sending back an ID token that proves who the user is.

Risk:
If OAuth is set up wrong, attackers could steal authorization tokens or use phishing to trick users into giving access.

Pro Tip: Always use the state parameter in OAuth flows to prevent CSRF attacks.

8. How can you mitigate XSS with CSP header?

Answer:
CSP (Content Security Policy) is a header that helps prevent XSS by telling the browser where it is allowed to load resources like scripts.

Example Policy:
Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com;

• ‘default-src ‘self”: Only allows resources from the same domain.
• ‘script-src ‘self”: Only allows scripts from trusted sources like the same domain or a trusted CDN.

How It Stops XSS:
If an attacker tries to inject a script, the browser will block it unless it’s from a trusted source.

9. Same Origin Policy (SOP) vs. CORS?

Answer:
– Same Origin Policy (SOP): SOP prevents scripts from one website (e.g., evil.com) from accessing data from another website (e.g., bank.com).
– CORS (Cross-Origin Resource Sharing): CORS allows servers to specify which websites can access their resources. This helps with safe sharing between websites.

Example:
A server can send a header like this to allow requests from app.com:
Access-Control-Allow-Origin: https://app.com

10. What HTTP Headers are used for implementing CORS?

Answer:
Key CORS headers are:

• Origin (Request):
  Shows where the request is coming from (e.g., https://app.com).
• Access-Control-Allow-Origin (Response):
  Tells which websites are allowed to access the resource.
• Access-Control-Allow-Methods:
  Lists allowed methods like GET, POST, etc.
• Access-Control-Allow-Headers:
  Lists the headers that can be included in the request.

Preflight Requests:
For complex requests, the browser first sends an OPTIONS request to check if CORS is allowed.