Interview Prep Zoneby CuriouserLabs

Question 5 of 5 · architect level

Beyond auth: harden a Spring Boot service — the vulnerabilities you actively design against.

🎤 Say this first

A checklist you own, not hope for: mass assignment (bind requests to dedicated DTOs/records, never entities); injection (parameterized queries always — including JPQL; encode output); actuator exposure (previous lessons applied); dependency CVEs (SBOM + scanners + a patch train — most Java breaches are known-CVE libraries, see Log4Shell); secrets hygiene; security headers (CSP, HSTS); SSRF (validate/allowlist outbound URLs users influence); deserialization (never native-deserialize untrusted bytes; strict Jackson typing); rate limiting at the edge; and audit logging with integrity. Bake it into the paved road (starter + CI gates) so services are hardened by default.

The full picture

Mass assignment: the quiet privilege escalation
// ❌ Binding straight to the entity:
@PostMapping("/users")                       //  {"name":"x","role":"ADMIN"} …
User create(@RequestBody User user) {        //  attacker sets ANY field
    return repo.save(user);
}

// ✅ A DTO that lists exactly what a client may set:
public record CreateUserRequest(@NotBlank String name, @Email String email) {}
@PostMapping("/users")
UserDto create(@Valid @RequestBody CreateUserRequest req) {
    return UserDto.from(service.register(req.name(), req.email()));
}   // role/tenant/id are assigned by CODE, never by input
  • Supply chain: bom.json (CycloneDX plugin) + OWASP Dependency-Check/Snyk in CI + Renovate auto-PRs + an org SLA ('critical CVE patched fleet-wide in 72h'). The Log4Shell question is really 'could you find and patch every affected service in a day?'
  • Injection breadth: JPQL/SQL concatenation (even 'internal' values), LDAP/command injection in integrations, and log injection (encode user input in logs — protects log4j-style parsing and SIEM integrity).
  • SSRF: any user-influenced outbound fetch (webhooks, image URLs, importers) gets scheme/host allowlists + no redirects-to-internal + metadata-endpoint blocking — cloud-credential theft via 169.254.169.254 is the canonical kill chain.
  • Headers & posture: HSTS, X-Content-Type-Options, minimal CSP for any served HTML; generic error bodies (your ProblemDetail work doubles as info-leak prevention); TLS everywhere including service-to-service (mesh/mTLS).
  • Detection: authz failures, authn anomalies and admin actions to structured audit logs → SIEM; an attack you can't see is one you can't answer for.

🔄 Likely follow-up questions

  • Walk through your Log4Shell-style response: discovery, patching, verification, comms.
  • How do you prevent tenant data leakage architecturally, not by code review?
  • What would a security review of your actuator + error handling + logging config look for?