Spring Framework Risk Assessment & Management 4 — Questions and Answers
Question 1: Which risk does relying solely on client-side validation introduce in a Spring MVC application?
- Server-side constraints become redundant and waste processing time
- Malicious clients can bypass client-side checks and send invalid or harmful data to the server (Correct answer)
- Spring's @Valid annotation is disabled when client-side validation is active
- The BindingResult object is never populated, hiding validation errors
Correct answer: Malicious clients can bypass client-side checks and send invalid or harmful data to the server
Client-side validation can be bypassed with tools like curl or Burp Suite, so server-side @Valid/@Validated constraints are essential for real enforcement.
Question 2: What risk does using @CrossOrigin(origins="*") on all Spring REST controllers introduce?
- Any website can make authenticated cross-origin requests to the API using the user's credentials (Correct answer)
- Spring Security's CSRF protection is automatically disabled for all origins
- Response payloads are cached by the browser, leaking sensitive data
- The wildcard origin prevents cookies from being sent with cross-origin requests
Correct answer: Any website can make authenticated cross-origin requests to the API using the user's credentials
A wildcard CORS policy allows any origin to call the API, potentially enabling cross-site request forgery or data exfiltration from authenticated sessions.
Question 3: In Spring Batch, what is a key risk of not configuring a job restart policy for long-running jobs?
- The job will automatically delete processed records on failure, causing data loss
- A failed job may reprocess already-completed items, causing duplicate data or transactions (Correct answer)
- Spring Batch will retry indefinitely, consuming all available threads
- Job metadata is never persisted, making the JobRepository unavailable
Correct answer: A failed job may reprocess already-completed items, causing duplicate data or transactions
Without proper restart strategy, Spring Batch may re-run completed steps from the beginning, leading to duplicate writes or inconsistent state.
Question 4: Which risk is introduced when Spring's @Async methods are configured without a custom executor?
- The default SimpleAsyncTaskExecutor creates an unbounded number of threads, risking thread exhaustion (Correct answer)
- Async methods run synchronously in the calling thread, negating concurrency benefits
- Spring throws an IllegalStateException when the context starts if no executor bean exists
- Async methods cannot access the security context set by Spring Security
Correct answer: The default SimpleAsyncTaskExecutor creates an unbounded number of threads, risking thread exhaustion
SimpleAsyncTaskExecutor spawns a new thread per task with no pool limit, so a traffic spike can exhaust server threads and cause an OutOfMemoryError.
Question 5: Which Spring Security feature directly reduces the risk of clickjacking attacks?
- Configuring X-Frame-Options or Content-Security-Policy frame-ancestors via headers (Correct answer)
- Enabling CSRF token validation on all state-changing endpoints
- Using BCrypt for password hashing with a high work factor
- Requiring HTTPS via HttpSecurity's requiresChannel() configuration
Correct answer: Configuring X-Frame-Options or Content-Security-Policy frame-ancestors via headers
X-Frame-Options: DENY or CSP frame-ancestors 'none' prevents the page from being embedded in iframes used by clickjacking attacks.
Question 6: What risk does storing Spring Security RememberMe tokens in a shared, non-persistent in-memory store introduce?
- Tokens are lost on application restart, requiring users to log in again but without additional security risk (Correct answer)
- Tokens survive application restart and can be replayed by attackers indefinitely
- All application nodes share the same token, enabling correct cross-node authentication
- Token theft is impossible because the in-memory store is not accessible externally
Correct answer: Tokens are lost on application restart, requiring users to log in again but without additional security risk
In-memory token loss on restart is a usability issue, not a security risk; however, if a persistent token store is used without secure handling, replay attacks become possible.
Question 7: Which approach best manages the risk of dependency vulnerabilities in a Spring Boot project?
- Pinning all transitive dependency versions manually in pom.xml
- Using the Spring Boot BOM and regularly running dependency audits with tools like OWASP Dependency-Check (Correct answer)
- Excluding all transitive dependencies and adding only direct dependencies
- Running the application behind a WAF to intercept exploit attempts
Correct answer: Using the Spring Boot BOM and regularly running dependency audits with tools like OWASP Dependency-Check
The Spring Boot BOM ensures compatible versions, while OWASP Dependency-Check identifies known CVEs in the dependency tree before they reach production.
Spring Framework Risk Assessment & Management 4
Which risk does relying solely on client-side validation introduce in a Spring MVC application?