Spring Framework Risk Assessment & Management 3 — Questions and Answers
Question 1: Which approach best mitigates the risk of mass assignment vulnerabilities in a Spring MVC REST API?
- Using DTOs instead of binding request bodies directly to JPA entities (Correct answer)
- Annotating all entity fields with @Column(updatable=false)
- Disabling Jackson's deserialization feature globally
- Using @RequestParam instead of @RequestBody for all inputs
Correct answer: Using DTOs instead of binding request bodies directly to JPA entities
DTOs expose only the fields the API intends to accept, preventing clients from overwriting fields like 'isAdmin' or 'id' on JPA entities.
Question 2: In Spring Security, what risk does permitting all requests to /api/** before securing sensitive sub-paths introduce?
- Increased response time due to multiple security filter evaluations
- Spring Security rules are evaluated in order, so the permitting rule may override later restrictive rules (Correct answer)
- The application will throw an AmbiguousRequestMappingException at startup
- CSRF tokens will not be validated on those endpoints
Correct answer: Spring Security rules are evaluated in order, so the permitting rule may override later restrictive rules
Spring Security's HttpSecurity rules are applied in declaration order, so a broad permit rule declared first will match before any narrower deny rules below it.
Question 3: Which risk is introduced when Spring beans are made prototype-scoped inside a singleton-scoped bean without special handling?
- The prototype bean is created once and reused, defeating the intent of prototype scope (Correct answer)
- A new singleton is created every time the prototype bean is requested
- Spring throws a BeanCurrentlyInCreationException at startup
- The prototype bean's lifecycle callbacks are never invoked
Correct answer: The prototype bean is created once and reused, defeating the intent of prototype scope
A singleton injects the prototype bean once at construction time, so every call uses the same instance, undermining prototype semantics.
Question 4: What is the primary security risk of enabling Spring Boot DevTools in a production deployment?
- DevTools disables Spring Security's CSRF protection automatically
- DevTools enables remote restart and live reload, which can expose the application to code injection (Correct answer)
- DevTools increases startup time, causing health check timeouts
- DevTools forces HTTP/1.1 and disables TLS
Correct answer: DevTools enables remote restart and live reload, which can expose the application to code injection
Spring Boot DevTools includes a remote restart server that, if accessible, allows arbitrary code execution on the production server.
Question 5: Which risk is associated with using @Cacheable without specifying a cache eviction policy in Spring?
- Unbounded cache growth leading to out-of-memory errors over time (Correct answer)
- Cached values are never returned, causing cache misses on every call
- The cache key defaults to null, overwriting entries for different arguments
- Spring throws CacheConfigurationException during context startup
Correct answer: Unbounded cache growth leading to out-of-memory errors over time
Without eviction settings, the cache grows indefinitely as new keys are added, eventually exhausting heap memory.
Question 6: When using Spring Cloud Config Server, which risk arises from storing secrets in plain text in a Git repository?
- Config Server cannot parse plain-text values and will fail to start
- Any developer or system with Git access can read production credentials (Correct answer)
- Plain-text properties are not served over the Config Server REST API
- Spring Boot clients will reject unencrypted property sources
Correct answer: Any developer or system with Git access can read production credentials
Git repositories grant read access to all stored content, so plain-text secrets are visible to everyone with repository access, including potential attackers.
Question 7: Which Spring Security mechanism helps assess and log authorization failures for risk auditing purposes?
- ApplicationEventPublisher listening for AuthorizationDeniedEvent or AbstractSecurityEvent (Correct answer)
- Enabling spring.security.debug=true in application.properties
- Annotating service methods with @Secured and @Audited together
- Using FilterSecurityInterceptor's default logging configuration
Correct answer: ApplicationEventPublisher listening for AuthorizationDeniedEvent or AbstractSecurityEvent
Publishing and listening to security events like AuthorizationDeniedEvent allows teams to log, alert, and audit unauthorized access attempts centrally.
Spring Framework Risk Assessment & Management 3
Which approach best mitigates the risk of mass assignment vulnerabilities in a Spring MVC REST API?