Web Security Interview Guide

This document consolidates the security interview discussion covering:

• Cross-Site Scripting (XSS)
• CSRF
• SQL Injection
• Frontend CSS vulnerabilities
• OWASP Top 10
• Java + React mitigation strategies
• Interview-ready answers

---

1. XSS — Cross-Site Scripting

What is XSS?

Cross-Site Scripting (XSS) occurs when an attacker injects malicious JavaScript into a web page and that script executes in another user’s browser.

XSS can allow attackers to:

• Steal sensitive information
• Manipulate the UI
• Perform actions on behalf of the user
• Access data available to JavaScript
• Potentially compromise user sessions

Types of XSS

Stored XSS

The malicious payload is stored on the server, commonly in a database, and executes whenever another user views the affected content.

Examples:

• User comments
• Profile fields
• Forum posts
• Product reviews

Reflected XSS

The malicious payload is supplied as part of a request and immediately reflected into the application’s response.

Common sources include:

• URL query parameters
• Search parameters
• Error messages

DOM-Based XSS

The vulnerability occurs entirely in client-side JavaScript when untrusted data is inserted into the DOM unsafely.

flowchart LR
    A[Attacker Input] --> B{XSS Type}
    B --> C[Stored XSS]
    B --> D[Reflected XSS]
    B --> E[DOM-Based XSS]

    C --> F[Stored in Server / DB]
    F --> G[Victim Views Content]

    D --> H[Request / URL]
    H --> I[Application Reflects Input]

    E --> J[Client-side JavaScript]
    J --> K[Unsafe DOM Manipulation]

    G --> L[Malicious Script Executes]
    I --> L
    K --> L

Preventing XSS in React

Output Encoding

React automatically escapes values rendered using normal JSX expressions:

<div>{userInput}</div>

The value is treated as text rather than executable HTML.

Avoid dangerouslySetInnerHTML

Avoid:

<div dangerouslySetInnerHTML={{ __html: userInput }} />

If HTML rendering is genuinely required, sanitize the HTML first.

Sanitization

Use a trusted HTML sanitizer such as DOMPurify when user-controlled HTML must be rendered.

Content Security Policy

Use CSP to restrict where scripts can originate and reduce the impact of injected scripts.

Avoid Unsafe DOM APIs

Be careful with:

• innerHTML
• document.write
• eval()
• Dynamic script creation
• Unsanitized HTML insertion

Interview Answer — XSS

“XSS occurs when an attacker injects malicious JavaScript that executes in another user’s browser. It can be stored, reflected, or DOM-based. In React, I rely on React’s automatic output escaping, avoid dangerouslySetInnerHTML, sanitize HTML when rendering it is unavoidable, use a strong Content Security Policy, and avoid unsafe DOM manipulation.”

---

2. CSRF — Cross-Site Request Forgery

What is CSRF?

CSRF tricks an authenticated user’s browser into sending an unwanted request to a trusted application.

For example, if a user is logged into a banking application, an attacker could trick the user’s browser into submitting a transfer request. If authentication cookies are automatically attached, the server may treat the request as coming from the legitimate user.

CSRF Flow

sequenceDiagram
    participant U as User
    participant B as Browser
    participant M as Malicious Site
    participant A as Target Application

    U->>A: Login
    A-->>B: Authentication Cookie
    U->>M: Visit malicious page
    M->>B: Trigger unwanted request
    B->>A: Request + authentication cookie
    A->>A: Process request if CSRF protection is missing

CSRF vs XSS

CSRF	XSS
Forces an authenticated user to perform an unwanted action	Injects malicious script into a trusted page
Commonly abuses automatically attached cookies	Executes attacker-controlled JavaScript
Does not necessarily require script execution in the target application	Requires JavaScript/content injection
Goal is usually an unauthorized state-changing action	Can steal data, manipulate UI, or perform actions

CSRF Mitigation

CSRF Tokens

Generate an unpredictable token and require it for state-changing requests.

SameSite Cookies

Use:

SameSite=Lax

or, where appropriate:

SameSite=Strict

Secure and HttpOnly Cookies

Use:

Secure
HttpOnly

Secure ensures cookies are transmitted over HTTPS.

HttpOnly prevents JavaScript from reading the cookie.

Origin / Referer Validation

Validate that sensitive requests originate from trusted origins.

Avoid State-Changing GET Requests

Use:

• POST
• PUT
• PATCH
• DELETE

for state-changing operations instead of GET.

Spring Security

For cookie/session-based applications, use Spring Security’s CSRF protection appropriately.

JWT Note

If a JWT is stored in an HttpOnly cookie, CSRF protection is still relevant because the browser automatically sends the cookie.

If a token is explicitly sent in:

Authorization: Bearer <token>

and is not automatically attached by the browser, traditional CSRF risk is significantly reduced.

Interview Answer — CSRF

“CSRF tricks a user’s browser into sending an authenticated request that the user did not intend to make. I mitigate it using CSRF tokens, SameSite cookies, Origin validation, secure cookie attributes, and by avoiding state-changing GET requests. With Spring Security, I configure CSRF protection appropriately for session or cookie-based authentication.”

---

3. SQL Injection

What is SQL Injection?

SQL Injection occurs when untrusted user input is directly concatenated into an SQL query, allowing an attacker to alter the intended SQL statement.

Vulnerable Code

String sql =
    "SELECT * FROM users WHERE name = '" + username + "'";

The problem is that user input becomes part of the SQL syntax.

Secure Approach

Use parameterized queries.

PreparedStatement statement =
    connection.prepareStatement(
        "SELECT * FROM users WHERE name = ?"
    );

statement.setString(1, username);

JPA / Hibernate

With Spring Data JPA:

@Query("SELECT u FROM User u WHERE u.name = :name")
User findByName(@Param("name") String name);

The parameter is kept separate from the query itself.

SQL Injection Prevention

• Use Prepared Statements
• Use Parameterized Queries
• Use Spring Data JPA repository methods
• Use JPQL/HQL named parameters
• Avoid string concatenation for SQL
• Validate input as an additional defense
• Apply database least privilege

SQL Injection Flow

flowchart TD
    A[User Input] --> B{How is input used?}
    B -->|String Concatenation| C[SQL Syntax Modified]
    C --> D[SQL Injection Risk]

    B -->|Parameterized Query| E[Input Treated as Data]
    E --> F[Safe Query Execution]

Interview Answer — SQL Injection

“I prevent SQL Injection by never concatenating user input into SQL. I use PreparedStatements and parameterized queries, and with Spring Data JPA or Hibernate I use repository methods or named parameters in JPQL/HQL.”

---

4. Frontend CSS Vulnerabilities

CSS is generally not treated like JavaScript, but unsafe styling, framing, and third-party resources can introduce security risks.

4.1 CSS Injection

CSS Injection occurs when attacker-controlled data is inserted into CSS in an unsafe manner.

Potential impact includes:

• UI manipulation
• Unexpected styling
• Information leakage in certain scenarios
• Bypassing intended presentation constraints

Prevention

• Validate CSS values
• Use allowlists
• Avoid inserting untrusted input into <style> blocks
• Avoid constructing CSS strings from raw user input

---

4.2 Clickjacking

Clickjacking tricks users into clicking a hidden or transparent iframe containing a target application.

The user believes they are clicking one thing, but the click is actually applied to another application.

flowchart LR
    A[Attacker Website] --> B[Transparent / Hidden iframe]
    B --> C[Target Application]
    U[User Click] --> B
    B --> D[Unintended Action]

Prevention

Use:

Content-Security-Policy: frame-ancestors 'self'

and, where appropriate:

X-Frame-Options: SAMEORIGIN

---

4.3 UI Redressing

UI Redressing manipulates the visual presentation so that users unknowingly perform an action.

Clickjacking is a common form of UI redressing.

Prevention

• Prevent unauthorized framing
• Use CSP frame-ancestors
• Use X-Frame-Options
• Keep sensitive actions clear
• Require confirmation for high-impact operations

---

4.4 Third-Party Stylesheet Risks

External CSS/CDN resources create a dependency on third-party infrastructure.

Risks include:

• Compromised third-party resources
• Unexpected changes
• Availability issues
• Supply-chain concerns

Prevention

• Use trusted sources
• Pin versions
• Minimize unnecessary third-party dependencies
• Prefer self-hosting for critical assets when appropriate
• Use Subresource Integrity (SRI) where supported

Interview Answer — CSS Security

“For frontend security, I consider CSS injection, clickjacking, UI redressing, and third-party resource risks. I validate dynamic CSS values, prevent framing with CSP and X-Frame-Options, minimize third-party dependencies, pin versions, and use SRI where applicable.”

---

5. OWASP Top 10

The OWASP Top 10 (2025) highlights major web application security risks.

1. Broken Access Control
2. Security Misconfiguration
3. Software Supply Chain Failures
4. Cryptographic Failures
5. Injection
6. Insecure Design
7. Authentication Failures
8. Software or Data Integrity Failures
9. Security Logging & Alerting Failures
10. Mishandling of Exceptional Conditions

Note: OWASP periodically updates the Top 10. For an interview, verify the version your organization expects you to discuss.

OWASP Security Model

flowchart LR
    R[React Frontend] --> G[API Gateway]
    G --> S[Spring Security]
    S --> A[Authentication]
    S --> Z[Authorization]
    G --> B[Spring Boot APIs]
    B --> D[JPA / Hibernate]
    D --> DB[(Database)]
    B --> L[Logging & Monitoring]
    C[Dependency Scanning] --> B
    K[Secure Configuration] --> B

---

6. OWASP Top 10 — Practical Mitigations

OWASP Risk	Typical Mitigation
Broken Access Control	RBAC, method-level authorization, server-side permission checks
Security Misconfiguration	Secure headers, CSP, disable unnecessary endpoints, secure configuration
Software Supply Chain Failures	Dependency scanning, version pinning, trusted packages, SBOM
Cryptographic Failures	HTTPS/TLS, strong password hashing, secure key management
Injection	Prepared statements, parameterized queries, JPA/Hibernate parameters
Insecure Design	Threat modeling, security requirements, secure design reviews
Authentication Failures	Spring Security, OAuth2/OIDC, JWT, MFA where appropriate
Software/Data Integrity Failures	Signed artifacts, dependency integrity, CI/CD controls
Security Logging & Alerting Failures	Centralized logs, audit events, monitoring and alerting
Mishandling of Exceptional Conditions	Secure error handling, validation, consistent failure responses

---

7. Which OWASP Vulnerabilities Have You Personally Mitigated?

A strong senior-level interview answer:

“In my projects, I have mainly worked on Broken Access Control, Authentication Failures, Injection, Security Misconfiguration, Cryptographic Failures, and Security Logging.

For example, I used Spring Security with JWT/OAuth2, role-based authorization, parameterized JPA queries to prevent SQL Injection, secure headers and CSP for frontend security, HTTPS and secure password hashing, and centralized logging and monitoring for security events. I also followed dependency scanning and secure configuration practices to reduce supply-chain and misconfiguration risks.“

Security Request Flow

sequenceDiagram
    participant U as User
    participant R as React
    participant S as Spring Security
    participant A as Spring Boot API
    participant J as JPA / Hibernate
    participant D as Database
    participant M as Monitoring

    U->>R: Login
    R->>S: Credentials / OAuth2
    S-->>R: Authenticated session/token

    R->>A: API Request
    A->>S: Authenticate + Authorize
    S-->>A: Access Granted

    A->>J: Parameterized Query
    J->>D: Execute Query
    D-->>J: Data
    J-->>A: Result

    A->>M: Security / Audit Event
    A-->>R: Response
    R-->>U: Render Result

---

8. Interview Quick Reference

XSS

Question: What is XSS?

Answer:

“XSS occurs when malicious JavaScript is injected into a web page and executed in another user’s browser. The main types are stored, reflected, and DOM-based XSS. In React, I rely on automatic output escaping, avoid dangerouslySetInnerHTML, sanitize HTML when required, use CSP, and avoid unsafe DOM APIs.”

---

CSRF

Question: What is CSRF and how do you prevent it?

Answer:

“CSRF tricks an authenticated user’s browser into performing an unwanted action. I mitigate it using CSRF tokens, SameSite cookies, Origin validation, secure cookie attributes, and by avoiding state-changing GET requests.”

---

SQL Injection

Question: How do you prevent SQL Injection?

Answer:

“I never concatenate user input into SQL. I use PreparedStatements and parameterized queries. With Spring Data JPA and Hibernate, I use repository methods and named parameters in JPQL/HQL.”

---

CSS Security

Question: What frontend CSS vulnerabilities have you encountered?

Answer:

“I consider CSS injection, clickjacking, UI redressing, and third-party stylesheet risks. I validate dynamic CSS, prevent unauthorized framing with CSP and X-Frame-Options, minimize third-party dependencies, pin versions, and use SRI where applicable.”

---

OWASP Top 10

Question: What are the OWASP Top 10 vulnerabilities and which have you mitigated?

Answer:

“The OWASP Top 10 covers major web application risks such as Broken Access Control, Security Misconfiguration, Supply Chain Failures, Cryptographic Failures, Injection, Insecure Design, Authentication Failures, Software/Data Integrity Failures, Security Logging & Alerting Failures, and Mishandling of Exceptional Conditions.

In my projects, I have personally worked on areas such as access control, authentication, injection prevention, secure configuration, cryptography, and security logging. I can explain the specific vulnerability, mitigation, and validation approach for each.“

---

9. Senior-Level Security Mindset

For a lead/senior engineer, do not stop at naming a vulnerability.

Explain the complete security lifecycle:

flowchart LR
    A[Identify Threat] --> B[Assess Risk]
    B --> C[Design Mitigation]
    C --> D[Implement]
    D --> E[Test]
    E --> F[Monitor]
    F --> G[Improve]
    G --> A

A strong answer should cover:

1. What is the vulnerability?
2. How can an attacker exploit it?
3. What is the impact?
4. What mitigation did you implement?
5. Where was the mitigation implemented — frontend, backend, infrastructure, or database?
6. How did you validate the fix?
7. How do you monitor for recurrence?

Final Interview Tip

Do not claim personal experience with vulnerabilities you have not actually handled.

A stronger answer is:

“I have personally worked on X, Y, and Z. For each one, I can explain the vulnerability, the mitigation we implemented, and how we validated it.”

This demonstrates practical security experience rather than simply memorizing the OWASP Top 10.